GDPR and documents: what the law says about uploading PDFs

You drag an invoice into a free online tool to shrink it. It has a client’s name, an address, maybe a tax ID. Five seconds later you have a smaller file and you move on. Did anything legal just happen?

Under GDPR, quite possibly yes. And most people never think about it, because the document looked harmless and the tool looked free.

This isn’t legal advice. I’m not your lawyer and every situation has its own details. But the shape of the rules is worth understanding, because it changes how you should handle documents that contain other people’s data.

What changes when the file leaves your machine

	You process it locally	You upload it to a web tool
Is it “processing” under the GDPR?	Yes — processing is any operation on personal data	Yes, and now someone else is doing it too
Who is the processor	Nobody but you	The site, which becomes a third party handling the data
Paperwork it triggers	None	A processing agreement under Art. 28
International transfer	None	Likely, if their servers sit outside the EEA (Ch. V)
Data minimisation (Art. 5.1.c)	Nothing is disclosed	The whole file goes, not just the part you needed
What a breach at their end exposes	Nothing of yours	Your document, and the notification duty is yours

What GDPR calls “processing”

What GDPR calls “processing”

People assume GDPR is about databases and marketing lists. The actual definition is much wider. Processing is almost anything you do with personal data: collecting it, storing it, reading it, changing it, sharing it, deleting it. The regulation literally lists “consultation” and “use” as forms of processing.

So when your PDF holds personal data (a name plus a phone number is already enough) and you do something with that file, you’re processing personal data. Compressing it counts. Merging it counts. Converting it counts.

That alone isn’t a problem. Businesses process personal data all day. The question GDPR asks is how you do it, and who else touches the data along the way.

Why uploading brings in a “processor”

Here’s where the cloud part matters. When you upload that invoice to an external service, the file leaves your control and lands on someone else’s servers. That company now processes the personal data on your behalf. GDPR has a name for them: a processor. You, the one who decided to do this, are the controller.

The moment a processor is involved, the controller picks up real duties. The big one is Article 28: you need a written contract with that processor, often called a Data Processing Agreement. It has to spell out what they can do with the data, how they protect it, when they delete it, and whether they can hand it to anyone else.

Stop and think about the free PDF tool you used last month. Did you sign a DPA with them? Did you read where their servers sit? Did you check who their subprocessors are? Almost certainly not. You uploaded a file with someone else’s personal data to a company you have no contract with. That’s the gap.

The international transfer trap

It gets thornier when the servers are outside the EU. Sending personal data to a provider in another country is a transfer, and GDPR restricts those. You need a valid legal basis for it, such as standard contractual clauses or an adequacy decision for that country.

Most free tools don’t tell you where they run. The file could be processed in a data center on another continent, passed through a queue, cached in a storage bucket, and you’d have no way to know. For a personal holiday photo, fine. For a contract full of client data, you’ve quietly made an international transfer you can’t document.

Minimization, the principle everyone forgets

GDPR has a principle called data minimization. You should only process the personal data you actually need, in the way that intrudes least. There’s a cousin principle too: think about privacy when you design a process, not after.

Apply that to a simple task like compressing a PDF. Do you need to send a client’s contract to a third-party server to make it smaller? No. The compression can happen on your own machine. Sending it out adds a processor, a contract you don’t have, and maybe a transfer you can’t justify, all for a file size change. That’s the opposite of minimization.

Why local processing sidesteps most of this

Here’s the part that makes the whole problem smaller. If the file never leaves your device, no third party processes it. No processor means no Article 28 contract to chase. Nothing crosses a border, so there’s no transfer to justify. You’re still the controller, you still owe the data subject the usual care, but a big chunk of the paperwork simply doesn’t apply, because nobody else touched the data.

This is the idea behind tools that run entirely in your browser. The code does the work locally, in your computer’s memory, and your PDF stays put. That’s how we built reader.me. When you compress a PDF, the file is processed in your browser and never reaches a server of ours. Open your browser’s DevTools, watch the Network tab, and you can confirm nothing with your document goes out.

Practical steps for businesses and freelancers

A few habits that keep you on the right side of things:

• Treat any document with names, IDs, or contact details as personal data. Invoices, contracts, CVs, and medical forms all qualify.
• Before uploading anything to a cloud tool, ask who the processor is. No DPA, no clear answer on server location? Don’t send client data through it.
• Default to local tools for routine jobs like compressing, merging, or splitting. If it can run in your browser, there’s no processor to vet.
• Keep a short record of which services touch personal data. GDPR expects controllers to know this anyway.
• When you genuinely need a cloud service, pick one that offers a real DPA and tells you where data lives.

The rules sound heavy, but the everyday fix is light. Most PDF work doesn’t need a server at all. Keep the file on your machine, and most of the legal weight never lands on you in the first place.