Are free PDF tools safe?

The short version

"Server-side" is not a synonym for "unsafe", and it is worth killing that idea before the table. Sending a file to a server is how you get OCR, how you handle a 2 GB document on a phone, and how you run conversions that no browser can do. Several of the tools below are run by established companies with real security programmes, and the ones with the tightest published retention windows are all server-side.

What server-side processing does change is the shape of the question. Once the file has left your machine, you are no longer relying on a fact you can observe — you are relying on a promise you cannot check. Every deletion commitment in this article is unverifiable from the outside. That is not an accusation; it is a structural property of the arrangement. The practical consequence is simple: match the tool to the document. A restaurant menu and a client's medical records do not warrant the same care.

Comparison table

Observed 23 August 2026 on the PDF compression tool of each service. Policies change; re-check before relying on this.

What the pattern actually shows

The result that surprised me least and matters most: browser-based PDF processing is rare. Ten of the 13 tools demonstrably upload, one demonstrably does not, and the two I could not settle both show signs of uploading. If you assumed that a tool advertising itself as "online" and "secure" keeps your file local, that assumption is wrong far more often than it is right.

The second pattern is in the policies rather than the packets. Stated retention windows range from thirty minutes to no stated period at all, and the spread does not track company size. CleverPDF, one of the smaller names here, publishes the tightest window and the only user-triggered immediate deletion. Two well-known services state no duration for the free web tool that I could find. Brand recognition is not a proxy for a good retention clause.

Third: read retention clauses for what they exclude. Sejda is the only policy here that says anything about backups, which matters because a backup is precisely the thing that outlives a deletion. Smallpdf's one-hour window is written as conditional on having an account. PDF2Go's strongest privacy language describes its desktop app, not the web tool. None of these are gotchas — they are just what the sentences say when you read them closely.

Per-tool notes

Methodology, so you can repeat it

Everything above came from two activities: watching a browser, and reading policies. Neither requires special tooling.

The network test

1. Make a test file you will recognise. I generated a 60-page, 57 KB PDF named observation-test.pdf containing nothing but synthetic filler text. A distinctive name matters: it shows up inside multipart upload bodies and makes an upload unambiguous. Never use a real document for this.
2. Open the tool in a fresh browser profile. A clean profile keeps old cookies and cached state from changing the tool's behaviour.
3. Open DevTools → Network, tick "Preserve log", and clear it immediately before you choose the file, so what you see afterwards is only what the file triggered.
4. Select the file, then run the tool. Some services upload the moment you choose a file; others wait until you press the action button. You have to do both before you can conclude anything.
5. Look for a request that carries the file. Filter to Fetch/XHR and look for a POST or PUT whose request payload is multipart/form-data,application/pdf, or roughly the size of your file. That is the file leaving.

The trap I fell into, and how to avoid it

My first pass reported that Smallpdf and Sejda did not upload. Both conclusions were wrong. Large uploads are frequently streamed, and a streamed request body does not always expose aContent-Length header or a readable payload to automated tooling — so a naive "look for a big request body" check misses them. Smallpdf's upload turned out to be aPUT with Content-Type: application/pdf to a Cloudflare R2 bucket, invisible to my original filter.

If you are checking by hand, the fix is to sort the Network panel and read the entries rather than relying on a size threshold. If you want certainty, use the second test.

The decisive test: pull the plug

1. Load the tool page completely and let it finish downloading its scripts.
2. In DevTools → Network, switch the throttling dropdown to Offline.
3. Now select your file and run the tool.

A tool that processes in your browser will finish the job with the network switched off. A tool that uploads cannot, and will usually tell you so. Sejda's own interface answered the question for me in plain English: "observation-test.pdf: Upload failed. There is no internet connection." This test has no false positives — a completed conversion with the network disabled cannot have involved a server.

One caveat. A browser-based tool may still fail offline the very first time, because the library that does the work may not have downloaded yet. Load the page, use the tool once online, reload, and only then go offline. That is how I tested my own site, and it is the only fair way to run it.

Reading the policies

For each service I searched its privacy policy for sentences containing both a retention verb (delete, retain, remove, store, purge) and a time expression, then read the surrounding paragraph to confirm what the sentence was actually about. That last step is not optional. PDF2Go's policy contains "The data is stored on our side for 7 days", which looks exactly like a file-retention period and is in fact about IP addresses in server logs. Quoting it as a file policy would have been a straightforward factual error.

Where I could not find a clause, the table says so rather than inferring one. "Not located" in this article means I looked and did not find it — it does not mean no such clause exists anywhere, and it is not a finding about how a company behaves.

Limits of this research

• One tool per service. I tested PDF compression only. A service can process one tool in the browser and another on a server; do not generalise a row to a whole site.
• One day. Everything here reflects 23 August 2026. Architectures get rewritten and policies get amended without announcement.
• Observation, not audit. Watching the network shows whether a file was sent. It says nothing about what happens afterwards — the security of the receiving infrastructure, whether deletion actually occurs, or who else can reach the data. Nobody can determine that from a browser, including me.
• Two unresolved rows. FreeConvert and PDF Candy are marked "not established" because my automation could not complete their flows. They are not marked as anything worse.
• Free tiers, signed out. I did not create accounts or test paid tiers, which may behave differently and are often covered by different terms.

What I would actually do

For an ordinary document — a flyer, a form you are about to print, a scan of something already public — any tool in this table is a reasonable choice, and the well-resourced server-side services will handle more formats and bigger files than a browser can.

For anything you would not email to a stranger — contracts, medical records, identity documents, unreleased financials, anything covered by an obligation to someone else — the calculus changes, because the risk is no longer yours alone to accept. There, in rough order of how much certainty each gives you: use desktop software that never touches a network; or self-host something like Stirling PDF so the server is yours; or use a browser-based tool and confirm with the offline test that nothing left; or, if you must use a hosted service, pick one with a short, specific, written retention period and delete the file manually afterwards if it offers that control.

And whichever you choose, the useful habit is the one this whole article is built on: open the network panel and look. It takes a minute, it works on any tool including mine, and it replaces a marketing claim with something you have seen for yourself.