Using File Tools at Work Without Creating a GDPR Problem
· 5 min read
Sending a document containing personal data to a third-party web tool generally makes that service a processor under Article 28, which requires a written agreement most free tools do not offer. Processing the file in your own browser avoids this, because no third party ever receives the data and there is no processor to appoint.
This catches out careful people constantly. Someone shrinks a client's scan so it fits an email, which takes five seconds and feels completely unremarkable, and in doing so sends a named individual's personal data to a company nobody has assessed. Nothing bad happens, and nobody notices — until an audit, or a breach at the other end.
On this page
Why uploading is a processing decision, not a convenience
Under the GDPR, if you decide how and why personal data is handled you are the controller, and anyone handling it on your behalf is a processor. A web tool that receives a document containing someone's name, address or medical details is doing exactly that.
Article 28 requires a controller to use only processors offering sufficient guarantees, and to have a written contract covering the arrangement. Clicking 'upload' does not create that contract, and a terms-of-service page you did not read is a weak substitute for one.
None of this depends on anything going wrong. The obligation exists at the moment the file is sent, whether or not the service behaves impeccably afterwards.
What counts as personal data here
The definition is broader than most people assume, and this is where the misjudgement usually happens. It is not limited to obviously sensitive records — anything that identifies a living person, directly or in combination with something else, qualifies.
- A name on an invoice or a letterhead
- A photograph of a person, including one in a scanned document
- An address, a phone number, an email address, a customer reference
- A signature — which is both personal data and, in some contexts, biometric
- Health, financial or employment information, which carries stricter obligations again
- A scanned identity document, which usually contains several of these at once
What a compliant arrangement normally requires
If you do use a third-party service for this, the expectation is not merely that you trust them. It is that you can show you assessed them, and that the paperwork exists.
This is entirely achievable with a paid service that sells to businesses, and it is one of the real reasons those services cost money. It is rarely achievable with a free tool, because the commercial relationship needed to support it does not exist.
| Requirement | Paid business service | Typical free web tool |
|---|---|---|
| Written processing agreement | Usually offered | Rarely offered |
| Named subprocessors | Usually published | Rarely published |
| Documented retention period | Contractual | A sentence in the terms |
| Transfer safeguards outside the EEA | Documented | Often unstated |
| Breach notification duty | Contractual | Usually absent |
Why local processing sidesteps the question
If the file never leaves the device, no third party has received personal data, so there is no processor to appoint and no agreement to obtain. The processing is being done by the controller, on the controller's own equipment, which is the ordinary case that the regulation was never troubled by.
This is also a much easier thing to explain to an auditor than a retention promise. 'The tool runs in the browser and the document is not transmitted' is a statement about how the software works, demonstrable in a minute with the Network tab open. 'They said they delete it after an hour' is a statement about someone else's intentions.
What local processing does not solve
It removes one specific exposure. It does not make you compliant, and treating it as though it does would be its own mistake.
You still need a lawful basis for holding the data at all, still owe the individual the usual rights, still have to keep the device itself secure, and still have to worry about where the file goes next. Compressing a document locally and then emailing it unencrypted to the wrong person is not an improvement on anything.
- The lawful basis for processing is unchanged
- Device security, disk encryption and access control still matter
- Retention on your own systems is still your responsibility
- Redaction is a separate problem — a black box drawn over text leaves the text underneath
- Where you send the file afterwards is where most real incidents actually happen
A practical rule for the office
Rather than assessing every site, decide by document. If it identifies a living person and it is not yours to disclose, do not upload it — use something local, whether that is a browser-based tool, the viewer built into your operating system, or licensed desktop software.
Keep the free web tools for material that is already public or genuinely impersonal. That single rule prevents almost every version of this problem, and it requires no legal knowledge to apply.
Common questions
Does uploading a document to a free tool breach the GDPR?
It can. If the document contains personal data, the service becomes a processor and Article 28 expects a written agreement with them. Free tools rarely provide one, which makes routine professional use difficult to justify.
Is a browser-based tool GDPR compliant?
Processing locally avoids appointing a processor, which is the specific problem, but no tool makes you compliant on its own. You still need a lawful basis, device security and sensible retention.
What if the tool says it deletes files after an hour?
That helps, but it is a policy rather than a mechanism, and it does not by itself satisfy the requirement for a processing agreement. Backups and logs also follow their own schedules.
Does this apply to a document with just a name on it?
Yes. A name identifying a living person is personal data. The obligations scale with sensitivity, but they begin far earlier than most people expect.
What about UK GDPR after Brexit?
The obligations here are materially the same. The processor requirement and the written agreement both survive in UK law, so the practical advice does not change.
How do I prove a tool did not upload the file?
Open developer tools, select the Network tab, clear it, and run the job — no request carrying the file means it stayed local. Running the tool with the connection switched off is a stronger demonstration still.
Is this legal advice?
No. It is a plain-language summary of a well-established obligation, written to help you ask the right question. For anything consequential, ask whoever handles data protection where you work.