Why Upload-Based Converters Increase Your GDPR Risk
Every upload-based converter is, in legal terms, a processor that receives a copy of your data. The moment you integrate one, a chain of obligations switches on.
Tools like CloudConvert, FreeConvert and Convertio are popular because they are easy to integrate: call an API, send a file, get a converted one back. What is easy for the developer, however, is often heavy for the data-protection officer, because the "send a file" step is exactly where the GDPR obligations begin.
This article maps where the data actually flows with a server-side converter, what that means under the GDPR, and how a client-side embed changes the equation.
Where the data flows with a server-side converter
- The user's file is uploaded from the browser to your backend.
- Your backend forwards it to the converter's API.
- The converter processes and stores it — possibly in another region.
- The result travels back; originals are deleted on a schedule you cannot verify.
At step two, the converter becomes a processor of personal data on your behalf, and at step three that data may cross a border. Both steps have legal consequences.
What that triggers under the GDPR
- A legal basis: you need one for sending customer files to a third party.
- A data processing agreement: required with every converter provider.
- Storage and deletion: you inherit responsibility for copies held by the provider.
- International transfer: if the provider processes outside the EEA, you need safeguards.
None of this is fatal, but it is real, ongoing work that scales with every file. See the full breakdown in our guide to client-side conversion and the GDPR.
Server-side API vs client-side embed
| Aspect | Server-side API | Client-side embed |
|---|---|---|
| File reaches your systems | Yes | No |
| Data processing agreement | Required | Not needed for conversion |
| Legal basis for file content | Required | Not needed |
| Storage and deletion duty | Yes | No |
| International transfer | Often a question | Not applicable |
What the comparison does not say
Client-side conversion removes the file content from the equation, not your other obligations. If your site runs analytics, advertising or error logging, those still process personal data and still need a lawful basis. And a client-side converter must still handle untrusted input safely. The honest conclusion is simply that, for the file conversion itself, the client-side option carries a materially smaller compliance surface.
A realistic caveat
None of this means server-side converters are forbidden or inherently unlawful. Thousands of organisations use them lawfully every day, with a processor agreement, a lawful basis and a retention policy. The point is narrower: every one of those organisations carries obligations that a client-side approach would not have created in the first place. When conversion is a small, low-value step in a larger workflow, that overhead is easy to avoid. Reserve the server-side path for cases where you genuinely need server compute, and let the browser handle the routine conversions.
In practice, the decision comes down to a simple question: does the file need to reach a server at all? When it does not, choosing the client-side path is the lower-risk option by default.
Frequently asked questions
Does using an upload-based converter make me a data controller?
If you direct the conversion, you remain responsible as controller for the file data you send to the converter. The converter acts as a processor, and you need a legal basis and a DPA.
What obligations does a server-side converter trigger?
A legal basis for the file content, a data processing agreement, storage and deletion duties, and possibly international-transfer safeguards.
How does client-side conversion differ?
The file never leaves the user's device, so you never receive it. The processing, storage and DPA obligations for the file content simply do not arise.