How Browser-Based PDF Tools Protect Privacy, Verifiably
Every online PDF tool says your files are safe. Files deleted after an hour, encrypted in transit, never shared. Those statements are often true, and they are all the same kind of thing: a promise about what a company chooses to do with a document you have handed over.
There is a different arrangement available, and the difference is not one of degree. It is the difference between a document that is protected by a policy and a document that was never sent anywhere at all.
The two models
Server-side. You choose a file, your browser transmits it, a machine somewhere processes it and returns a result. Between those steps your document exists on hardware you do not control. What happens there is governed by the operator’s policy, their security, their staff, their jurisdiction, and their backups. You are asked to trust all of it, and you cannot inspect any of it.
Client-side. The page you loaded contains the program. Your file is opened by the browser, processed in your machine’s memory, and written back to your disk. The document never becomes a network request.
The distinction that matters: in the first model your privacy depends on what someone does with your file. In the second it depends on the file never reaching them. Only one of those is a property you can check.
Why “deleted after an hour” is the wrong reassurance
Retention policies address the wrong risk. The risk is not usually that a company hoards your document — it is everything that can happen in the window while it is there.
The upload itself is logged somewhere. It sits on a disk that gets backed up. It passes through a load balancer, a queue, a worker process, each with its own logs. It is in the reach of anyone with production access, and of anyone who compromises production. It falls under whatever legal process applies in the country the server sits in. And a deletion promise is only as durable as the company: policies change, companies are acquired, and terms are rewritten.
None of this makes server-side tools disreputable. It makes them a trust relationship, appropriate when you are comfortable with the counterparty. For a menu you are combining, fine. For a medical record, a tax return, a contract under negotiation, or a set of bank statements, the calculation is different — and those are exactly the documents people most often need a PDF tool for.
The mechanism that makes it enforceable
This is where a claim becomes something more than a claim.
A web page can declare a Content Security Policy — a set of rules the browser enforces, not the site. One of those rules, connect-src, states which origins the page is permitted to make network requests to.
The pages on this site are served with connect-src 'self'. That instructs your browser to block any attempt by this page to send data anywhere other than back to this site’s own origin. It is not a setting the page can quietly override at runtime; it arrives in the response headers before any of the page’s code runs, and the browser enforces it against that code.
The practical consequence: even if this site’s code tried to upload your document, your browser would refuse to make the request. The guarantee does not rest on our good intentions. It rests on a mechanism your browser applies to us.
Alongside it, the same headers set object-src 'none', frame-ancestors 'none' so the site cannot be embedded in someone else’s page, and a permissions policy that switches off camera, microphone, geolocation, payment, and USB access entirely.
Check it yourself, in two minutes
None of the above is worth much if you take it on faith. Both of these are things you can do right now.
Watch the network. Open your browser’s developer tools, select the network panel, then merge two PDFs or compress a scan. Watch what happens as you do. You will see the page’s own files load, and then nothing — no request carrying your document, because none is made.
Work offline. Load a tool page, disconnect from the internet, then use it. It keeps working, because there was never anything on the other end of a connection. This is the most convincing test there is: a tool that functions with the network unplugged cannot be sending your file anywhere.
A server-based tool fails the second test immediately and visibly.
Reading a privacy policy usefully
If you are evaluating any PDF tool, including this one, the policy is worth two minutes — but only if you know which sentences carry weight.
Look for the mechanism, not the adjective. “Secure”, “private”, and “safe” are not claims; they describe a feeling. “Files are processed in your browser and are not uploaded” is a claim, because it can be false.
Check whether the promise is about deletion or about transmission. “Deleted after one hour” concedes that the file was uploaded and stored. That may be perfectly acceptable — but it is a fundamentally different statement from “not uploaded”, and the two are often placed close enough together to blur.
Look for what happens on failure. Many policies describe the happy path only. What is logged when processing errors? Are filenames retained even when contents are not? A filename can be the sensitive part.
Notice what is not mentioned. Analytics, embedded fonts loaded from third parties, error-reporting services, advertising. Each is a separate connection your document’s metadata may travel over even when the file does not.
What this design costs
Presenting only the advantages would be its own kind of dishonesty. Local processing has real trade-offs, and they are worth knowing before you rely on it.
Your hardware is the ceiling. A fifty-page scan is processed by your laptop, not by a datacentre. Large jobs take real time and can exhaust a browser tab’s memory. Merging in batches is the usual workaround.
Some things are genuinely impossible here. A certificate-based digital signature needs a certificate authority to verify your identity — an inherently external service. No browser tool can provide one; see electronic signature vs digital signature.
Nothing is stored for you. No account, no history, no documents waiting when you return. Close the tab and the session is gone. That is the point, and it is occasionally inconvenient.
First load is heavier. The processing code has to reach your machine, because your machine is doing the work.
A fuller comparison against installed software is in browser PDF tools vs desktop software.
The metadata question
One more thing worth separating out, because it is the gap most often overlooked when people reason about this.
Even where a document’s contents never leave your machine, its existence can. A tool that loads a font from a third-party host, reports errors to a monitoring service, or runs analytics is making requests while you work — and those requests carry your address, your browser, the page you are on, and the timing of what you did.
None of that is your document. Some of it is still informative. “Someone at this address used the unlock tool at 2am” is not the file, but it is not nothing either.
The way to close that gap is not a policy but an absence: no third-party hosts at all. That is what the connection rule above enforces, and what the site’s own third-party licence page reflects — every library used here is served from this origin rather than from a content delivery network, precisely so that using a tool creates no connection to anyone else.
What this does not protect you from
Local processing removes one risk. It does not remove the others, and it would be misleading to imply otherwise.
- Your own device. If it is compromised, everything on it is exposed regardless of where the processing happened.
- What you do next. Emailing the result puts it on mail servers. Local processing protects the operation, not the document’s whole life.
- Anyone with access to your machine, including a shared or work computer.
- Backup and sync. A file in a synced folder is already in the cloud before you open any tool.
Privacy is a chain. This removes one weak link — a significant one — and leaves the rest to you.
Where encryption belongs in this
Local processing protects the document while you work on it. If it then has to travel, that is a separate problem with a separate answer: encrypt it before sending, and share the password through a different channel. How to password-protect a PDF covers doing that properly, including what encryption does not cover.
The two combine well. Assemble and check the document locally, encrypt as the final step, send the encrypted file. At no point does an unprotected copy leave your control.
The format’s part in it
That any of this works locally at all is a consequence of PDF being an open, documented standard rather than a proprietary format. ISO 32000-2 specifies the structure in enough detail that independent software can read and write it correctly, which is why a browser can do this work without anyone’s permission or server. The PDF Association publishes reference material on what the standard covers.
An open standard is a privacy feature, even though it is never described as one. A format only its vendor can process is a format whose vendor you must involve.