Bestandsconversie in de browser en de AVG: waarom client-side je aansprakelijkheid verkleint

Elk bedrijf dat klantbestanden verwerkt — foto's, scans, documenten, spreadsheets — erft dezelfde vraag: wat gebeurt er met de data zodra ze het apparaat van de klant verlaten? Bij een klassieke upload-converter is het antwoord ongemakkelijk. Het bestand reist naar een server die jij beheert (of huurt), rust in opslag en wordt verwerkt door infrastructuur waarvoor jij onder de AVG verantwoordelijk bent.

Client-side conversie draait dat model om. Het bestand wordt volledig in de browser gelezen, verwerkt en teruggestuurd, zodat het jouw systemen nooit bereikt. Deze gids legt uit waarom dat ertoe doet voor de AVG, welke verplichtingen daardoor vervallen en waar de techniek echt helpt — en waar niet.

De standaard: server-side conversie

De meeste conversiediensten werken zo:

1. De gebruiker selecteert een bestand in de browser.
2. Het bestand wordt geüpload naar jouw server of een API van derden.
3. De server decodeert, converteert en slaat het resultaat op.
4. De gebruiker downloadt het resultaat; de server verwijdert de bestanden na een bewaartermijn.

Vanuit de AVG is dat de dure route. Jij (of je verwerker) wordt ontvanger van persoonsgegevens, wat een keten van verplichtingen in gang zet: een rechtsgrond, een verwerkersovereenkomst, technische en organisatorische maatregelen, bewaartermijnen, meldplichten en, bij internationale doorgifte, een adequaatheids- of waarborgenanalyse.

Niets daarvan is onmogelijk, maar het is echt en doorlopend werk dat meegroeit met elk bestand dat je accepteert.

Wat client-side conversie echt betekent

Moderne browsers brengen alles mee om bestanden lokaal te converteren: de Canvas-API om afbeeldingen te decoderen en hercoderen, Web Workers om de interface vloeiend te houden en WebAssembly-bibliotheken voor zwaardere formaten zoals HEIC, PDF of OCR. Als de conversie zo draait:

• Het bestand wordt alleen door de browser gelezen, in het geheugen.
• Het wordt gedecodeerd en hercodeerd op het apparaat van de gebruiker.
• Er wordt niets over het netwerk verstuurd.
• Het resultaat wordt terug op het apparaat opgeslagen.

Er is geen serverkopie te beveiligen, bewaren of verwijderen, omdat er nooit een kopie is gemaakt. Dat is het model van FormatFlash, en de reden waarom het eerlijk kan zeggen dat bestanden het apparaat van de gebruiker nooit verlaten.

Waarom dit telt onder de AVG

De AVG draait om dataminimalisatie en controle. Client-side verwerking sluit daar van nature bij aan:

• Dataminimalisatie (art. 5 lid 1 sub c): je ontvangt geen kopie, dus je houdt de kleinst mogelijke hoeveelheid data: geen.
• Privacy by design (art. 25): de architectuur voorkomt verzameling in plaats van die achteraf te beperken.
• Geen internationale doorgifte: data die het apparaat niet verlaat roept geen adequaatheidsvraag op.
• Geen opslagplicht: er valt niets te bewaren, versleutelen of verwijderen.

Voor een FG of een inkoopteam is het praktische effect dat een hele sectie van het verwerkingsregister als «niet van toepassing» kan worden gemarkeerd.

Welke verplichtingen vervallen

Wat nooit verdwijnt, is je verantwoordelijkheid voor de code die je publiceert: laadt je site analytics, advertenties of foutregistratie, dan verwerken die nog steeds persoonsgegevens en hebben ze een rechtsgrond nodig. Client-side conversie haalt de bestandsinhoud uit de vergelijking; het haalt tracking niet weg.

Waar client-side conversie het meest helpt

HEIC en mobiele foto-uploads

iPhone-foto's komen binnen als HEIC. Converteren op het apparaat van de gebruiker betekent dat je een formaat dat je backend misschien niet ondersteunt, nooit binnenkrijgt. Zie wat HEIC is en HEIC naar JPG op de iPhone.

EXIF- en GPS-metadata

Lokale her-codering verwijdert standaard ingebedde metadata zoals EXIF en GPS-coördinaten. Voor klantfoto's is dat een echte minimalisatiewinst — zie de gids voor het verwijderen van EXIF en GPS.

OCR en gescande documenten

Scans van identiteitsbewijzen, contracten of formulieren behoren tot de gevoeligste bestanden. Lokaal OCR draaien houdt ze buiten je servers — zie OCR zonder upload.

Wat client-side conversie niet oplost

• Analytics en cookies: gebruik je Google Analytics, dan blijven de toestemmingsregels gelden.
• Serverlogs: hosting registreert altijd technische data (IP, user agent).
• Kwaadaardige invoer: client-side code moet onbetrouwbare bestanden veilig afhandelen.
• Eigen verzamelpunten: ontvang je hetzelfde bestand apart voor een ander doel, dan heeft die verwerking een eigen rechtsgrond.

Zo beoordeel je een converter op compliance

1. Bevestig dat de tool bestanden lokaal verwerkt — houd het netwerk-tabblad in de gaten voor uploads.
2. Controleer dat het privacybeleid zegt dat bestanden het apparaat nooit verlaten.
3. Vergewis je ervan dat geen enkele API van derden het bestand tijdens de conversie ontvangt.
4. Let op metadata-omgang: een standaard die EXIF/GPS verwijdert is een plus.
5. Vraag of een verwerkersovereenkomst überhaupt nodig is — zonder doorgifte is die dat meestal niet.

Veelgestelde vragen

Gerelateerde gidsen

• Waarom client-side HEIC-conversie telt
• EXIF en GPS verwijderen: de compliance-gids
• OCR zonder upload
• Embed-integratie voor ontwikkelaars

Voor een concrete, inbedbare client-side converter zie FormatFlash Embed of gebruik direct de gratis afbeeldingsconverter.

Bestanden privé converteren