Are online PDF tools safe? What '0 uploads' really means

You found a free site that merges, compresses, or unlocks a PDF in seconds. It looks clean, it works, and a little banner promises your file is “deleted after one hour.” So the question is fair: are these tools actually safe?

The honest answer is “it depends” — and most of the time it depends on something you can’t see from the page itself. Let’s make the invisible part visible, without fear-mongering.

Most “online” tools upload your file

Here is the part nobody puts in big letters: the majority of PDF tools you find online send your document to a remote server. The processing — merging, OCR, conversion — happens on their machine, not yours. That’s not a scandal by itself; it’s just how server-side software works. The PDF leaves your computer.

The promises that follow (“we delete files after 1 hour”, “we never look at them”) may be completely sincere. The problem is that you can’t verify them. Once your file is on someone else’s server, you are trusting:

• Their retention policy. “Deleted after an hour” is a setting, not a law of physics. Logs, backups, and caches can keep copies longer than the user-facing promise.
• Their security. Servers get breached. A document that never left your laptop can’t leak in someone else’s breach.
• Their third parties. Many tools run on infrastructure they don’t own and pass files through processing services, queues, or storage buckets you’ll never see.

None of this means every online tool is malicious. It means “trust me” is the entire security model, and for an invoice, a contract, a medical report, or an ID scan, that may not be enough.

What “0 uploads” actually means

A genuinely client-side tool does something different: it never sends your file anywhere. The code that processes the PDF is downloaded to your browser once, and then your document is opened, parsed, and modified entirely in your device’s RAM.

The engine behind this is usually WebAssembly — compiled code (often the same libraries used server-side) running inside the browser sandbox at near-native speed. Your PDF is read as bytes in a memory buffer, transformed, and written back out as a new file you download locally. Close the tab and that memory is gone. There was no server in the loop because there didn’t need to be one.

This is what “0 uploads” should mean, literally: zero network requests carrying your file. Not “uploaded then quickly deleted” — never uploaded at all.

How to tell the difference (open DevTools)

You don’t have to take anyone’s word for it, including ours. Your browser ships with the proof:

1. Open the PDF tool, but don’t drop your file in yet.
2. Press F12 (or right-click → Inspect) and go to the Network tab.
3. Click the record/clear button so you start fresh.
4. Now run the operation — add your file and hit the button.
5. Watch the requests. A client-side tool shows the file being read locally and no outgoing request containing your document. A server-side tool shows a clear upload (often a POST with your file size in the payload) followed by a download of the result.

If you see your 4 MB PDF being sent in a request body, it was uploaded — no matter what the banner says. If the only network traffic is the page assets and maybe analytics pings, your file stayed on your machine.

A trust checklist

Before you hand a sensitive PDF to any web tool, run through this:

• Does it process client-side? Check the Network tab. This is the single most important test.
• Does it still work offline? Truly client-side tools keep working with Wi-Fi off after the page loads. Server tools break immediately.
• Is the privacy claim specific? “Processed in your browser, never uploaded” is verifiable. “We respect your privacy” is not.
• What does analytics see? Page-view tools like Google Analytics or Cloudflare can log that you visited and which page — but they never see the contents of your PDF. Knowing the difference matters.
• Is the encryption honest? If a tool password-protects your PDF, ask which standard. Stronger isn’t always used, and you should know.

Where files.co stands — honestly

We build files.co as client-side first, so the DevTools test above is the whole point. Open the Network tab, run a merge or a compress, and you won’t find your PDF in any request. It’s processed in your browser’s RAM with WebAssembly and never sent to us.

Two clarifications we’d rather state plainly than bury. First, our Protect tool encrypts PDFs with AES-128, not AES-256. AES-128 is strong and standard for PDF password protection, but we won’t claim a number we don’t ship. Second, we do use analytics — Google Analytics and Cloudflare — which see page views and traffic, the same as almost any website. They do not see your file’s contents, because your file never leaves your device for them to see.

Online PDF tools aren’t inherently unsafe. But “safe” should be something you can check, not something you have to believe. Open DevTools, watch the Network tab, and let the file — or its absence — speak for itself.