Why Your PDFs Should Never Leave Your Device

A colleague once uploaded a rental agreement to a "free PDF compressor" she found on Google. She got a smaller file back. What she didn't notice was that the tool had asked for her email address "for the download link" — and that the terms of service mentioned her uploaded files "may be used to improve our services."

She never found out exactly what that meant. Nobody reads the terms of service on free online tools. That's the problem.

This article is about what happens to your files when you upload them to an online tool, and why "runs in your browser" is the only honest answer to the privacy question.

What actually happens on upload

When you drag a PDF into a web tool that uploads, the sequence looks roughly like this:

1. Your browser sends the file to a server. Over HTTPS, encrypted in transit. The server decrypts it as soon as it arrives.
2. The server stores it somewhere. Usually in a temporary directory, sometimes in object storage like S3.
3. The server processes it. Merges, compresses, signs — whatever the tool does.
4. The server returns a link or file. Often through a CDN.
5. The file is deleted — "within an hour", "within 24 hours", "within 7 days" — depending on the tool's claim.

Between steps 2 and 5, your file exists in at least one other party's infrastructure. You can't verify what happens to it there. You can't verify the deletion actually happens. You can't verify it wasn't logged, cached, indexed, or backed up along the way.

For a public-domain recipe PDF, none of this matters. For a rental agreement, medical record, or legal contract, it matters a lot.

The claims vs the reality

Most online PDF tools make privacy claims. Let's look at what those claims actually mean.

"Files deleted within 1 hour"

This means: the file is stored on their server, and they promise to delete it within an hour. It does not mean the file was never readable by their systems during that hour. It does not mean logs of the file's existence (or the filename, or your IP) weren't retained. It does not mean the file wasn't processed by third-party services like Cloudflare or AWS, each with their own retention.

Also: you're trusting the promise. You can't audit a server you don't control.

"End-to-end encrypted"

This phrase is widely misused. True end-to-end encryption means only you (the sender) and the recipient can decrypt — no server in the middle can read it. For a PDF tool that uploads, processes, and returns a file, end-to-end encryption is not possible by definition: the server has to decrypt the file to process it.

Some tools mean "we use HTTPS" (which only protects transit, not storage) and call it "encrypted". That's misleading at best.

"We don't sell your data"

Perhaps. But "don't sell" and "don't use" are different things. Many free tools monetise through:

• Ad networks that also get page-level analytics
• Data brokers receiving aggregated metadata
• AI training datasets (rarely disclosed for file content)
• Being acquired later, with the files as part of the deal

Even a well-intentioned free tool changes its terms when it's acquired. Your earlier files, if retained, become subject to the new terms.

Why this matters more than you think

Three scenarios where "upload to a random server" is a genuine problem:

Legal and financial documents

Contracts, tax returns, bank statements, medical records, ID documents. In many jurisdictions, sending these to a third party without a lawful basis is itself a compliance issue. GDPR in Europe, DPDP in India, and CCPA in California all have provisions about this.

Confidential work material

Internal business plans, customer lists, employee records. If your employer has an information-security policy, using an online tool for these documents may be a policy violation — even if you only intended to compress a slide deck.

Personal metadata

Even if the content of a file is uninteresting, the file itself carries metadata: author name (often your real name or computer username), creation timestamp, and sometimes the full original filename. That's a fingerprint. Upload it to a server that logs access, and you've signed your name to a database entry.

We wrote about this in more detail in our article on PDF metadata.

How to verify a tool is local

You don't have to take a tool's word for it. Here's how to check:

Method 1: Watch the network tab

1. Open your browser's Developer Tools (F12 or Ctrl+Shift+I).
2. Go to the Network tab.
3. Clear any existing requests.
4. Use the tool with a test file.
5. Watch for any request whose payload is roughly the size of your file.

If your file is 5 MB and you see a 5 MB outgoing POST request, the tool is uploading. If you see no such request, the tool is processing locally.

Method 2: Disconnect from the internet

Load the tool page. Then turn off your Wi-Fi / unplug Ethernet. Try to use the tool.

If it works, the processing was local. If it fails, it needed the server.

This is the definitive test. It's also why we tell people: try DSPDF with the internet off. It works. That's the proof.

Method 3: Read the JavaScript

For the technically inclined: view the page source. Look for FormData with file appends, fetch() calls pointing to non-static endpoints, or XMLHttpRequest with file bodies. If you find one, the file is being sent somewhere.

Our tool pages load exactly two kinds of scripts: our own (from /js/) and well-known open-source libraries from public CDNs (pdf-lib, pdf.js, Tesseract). None of them transmit your file.

The physics of client-side processing

Why is it even possible to do all this in the browser? Because browsers got genuinely powerful.

Modern browsers have:

• FileReader and File APIs — read local files without uploading them
• Canvas and WebGL — render pages at any resolution
• WebAssembly — run near-native-speed code compiled from C++ (Tesseract OCR uses this)
• Web Workers — do heavy computation off the main thread without freezing the UI
• Blob and download APIs — save files without a server
• File System Access API — even read and write to local folders, with permission

Ten years ago, some of these operations were genuinely impossible in a browser. Today they're routine. There's no longer a technical reason most PDF operations need a server.

The reason most tools still use servers is: servers are easier to build, easier to monetise, and easier to hide what's happening inside.

FAQ