Browser-Based File Conversion and the GDPR: Why Client-Side Processing Reduces Your Liability
When files are converted on the user's device instead of on your servers, a large part of your data-protection obligation simply never arises.
Every business that handles customer files — photos, scans, documents, spreadsheets — inherits the same question: what happens to the data the moment it leaves the customer's device? With a classic upload-based converter, the answer is uncomfortable. The file travels to a server you control (or rent), rests in storage, and is processed by infrastructure you are legally responsible for under the GDPR.
Client-side conversion flips that model. The file is read, processed and written back entirely inside the browser, so it never enters your systems at all. This guide explains why that matters for the GDPR, which obligations shrink as a result, and where the technique genuinely helps — and where it does not.
The default: server-side conversion
Most conversion services work like this:
- The user selects a file in their browser.
- The file is uploaded to your server or a third-party API.
- The server decodes, converts and stores the result.
- The user downloads the output; the server deletes the files after a retention window.
From a GDPR standpoint this is the expensive path. You (or your processor) become the recipient of personal data, which triggers a chain of obligations: a legal basis for processing, a data processing agreement with any processor, technical and organisational measures, deletion schedules, breach-notification duties and, for international transfers, an adequacy or safeguards analysis.
None of this is impossible — enterprises do it every day. But it is real, ongoing work, and it scales with every file you accept.
What client-side conversion actually means
Modern browsers ship with everything needed to convert files locally: the Canvas API to decode and re-encode images, Web Workers to keep the UI responsive, and WebAssembly libraries for heavier formats such as HEIC, PDF or OCR. When conversion runs this way:
- The file is read by the browser only, in memory.
- It is decoded and re-encoded on the user's device.
- Nothing is transmitted over the network.
- The result is saved back to the user's device.
There is no server copy to secure, retain or delete, because no copy was ever created. This is the model used by FormatFlash and the reason it can truthfully state that files never leave the user's device.
Why this matters under the GDPR
The GDPR is built around the idea of minimising data and keeping it under control. Client-side processing aligns with that by design:
- Data minimisation (Art. 5(1)(c)): you receive no copy, so you hold the smallest possible amount of data — none.
- Privacy by design (Art. 25): the architecture itself prevents collection rather than mitigating it after the fact.
- No international transfer: data that never leaves the user's device raises no adequacy or standard-contractual-clause question.
- No storage obligation: there is nothing to retain, encrypt, or delete on your side.
For a DPO or a procurement team, the practical effect is that a whole section of the processing register can be marked "not applicable".
Which obligations shrink
| Obligation | Server-side conversion | Client-side conversion |
|---|---|---|
| Data processing agreement (DPA) | Required with any processor | Not needed for the conversion itself |
| Legal basis for file content | Needed | Not needed — you never receive it |
| Deletion schedule | Needed | Not applicable |
| Breach notification exposure | Files at risk | No file data at risk |
| International transfer safeguards | Often needed | Not applicable |
| TOM for file storage | Needed | Not applicable |
The one thing that never disappears is your responsibility for the code you ship: if your site loads analytics, advertising or error-logging scripts, those still process personal data and still need a lawful basis. Client-side conversion removes the file content from the equation — it does not remove tracking.
Where client-side conversion helps most
HEIC and mobile photo uploads
iPhone photos arrive as HEIC. Converting them on the user's device means you never ingest a format that your backend may not even support. See what HEIC is and how to convert HEIC on iPhone.
EXIF and GPS metadata
Local re-encoding removes embedded metadata such as EXIF and GPS coordinates by default. For customer photos this is a genuine data-minimisation win — see the EXIF and GPS removal guide.
OCR and scanned documents
Scans of ID cards, contracts or medical forms are among the most sensitive files a business touches. Running OCR locally keeps them off your servers entirely — see OCR without upload.
What client-side conversion does not solve
Be honest in your threat model. Client-side processing does not remove:
- Analytics and cookies: if you run Google Analytics or similar, consent rules still apply.
- Server logs: hosting always records some technical data (IP address, user agent).
- Malicious input: client-side code still has to handle untrusted files safely.
- Your own collection points: if you separately receive the same file for another purpose, that processing needs its own basis.
How to evaluate a converter for compliance
- Confirm the tool processes files locally — watch the network tab for uploads.
- Check the privacy policy states that files never leave the device.
- Verify that no third-party API receives the file during conversion.
- Look for metadata handling: a default that strips EXIF/GPS is a bonus.
- Ask whether a DPA is even necessary — with no data transfer, it usually is not.
Frequently asked questions
Does client-side conversion count as data processing under the GDPR?
Processing by the end user on their own device for their own purposes is generally not processing by your organisation, because you never receive the data. What remains is your responsibility for the code you ship and for any technical logs.
Do I still need a data processing agreement for client-side conversion?
If no personal data reaches a processor, there is typically nothing to regulate with a DPA. A DPA is still relevant if you pass data to a hosting or analytics provider.
Is browser-based conversion reliable for HEIC files?
Yes. Modern browsers can decode HEIC locally using a WebAssembly decoder, so HEIC to JPG or PNG happens entirely on the user's device.
What happens to EXIF and GPS metadata?
Local re-encoding removes embedded metadata such as EXIF and GPS by default, which is itself a data-minimisation benefit when sharing photos.
Related guides
- Why client-side HEIC conversion matters
- EXIF and GPS removal: the compliance guide
- OCR without upload: scan-to-text, locally
- Embed integration for developers
For a concrete, embeddable client-side converter, see FormatFlash Embed or use the free image converter directly.