What happens to a file you upload to a free PDF site

You drop a contract onto a free compression site, a progress bar fills, a smaller file comes back. Thirty seconds, free, with no account. It's a good product experience, and tens of millions of people use these tools every month without thinking about the file's route. So: in those thirty seconds, where did the contract go?

Disclosure before the argument: we build browser-based PDF tools, so we are not neutral about the answer. Everything below is checkable, and the last section shows how to check it, on this site too.

Where an uploaded PDF actually goes

Mechanically, an upload-based tool works like any web service. Your browser transmits the file (encrypted in transit, on any competent site) to the company's servers, which in practice usually means cloud infrastructure rented from Amazon, Google or a similar provider, in whatever country that infrastructure sits. The file lands in storage, waits its turn in a processing queue, gets worked on by the conversion software, and the result is written back to storage, where a download link points at it. Some time later, minutes to days depending on the service, a cleanup job deletes both copies.

It is a standard, sensible architecture, run by diligent people. But for that window, your document exists as plaintext on another company's computers, in whatever country that company happens to run them.

Who pays for the server

Processing millions of files costs real money: compute, storage, bandwidth, engineers on call. A free tool has to cover that somehow, and the mainstream ways are visible on the sites themselves: ads, daily limits and file-size caps that push heavy users to a paid tier, and a subscription prompt at the point where the file is already processed and the download button is right there.

That model is legitimate, and it's how most of the industry operates. It has one structural consequence: the free tier exists to create paying customers, so the limits are set by marketing rather than by engineering, and they are designed to be hit. Knowing that spares you the afternoon of hunting for the service with the loosest cap.

What "deleted after two hours" promises, and what it can't

Nearly every upload-based tool's privacy page says files are deleted automatically after some window. Take the claim at face value; there is no reason to think the major services don't delete on schedule. Read instead for what the sentence does and doesn't cover.

The promise confirms the file was on a server in the first place: a deletion schedule only exists for documents a server received. Around the deleted file, other records normally persist: server logs of the transaction, your IP address, the filename, timestamps. And deletion says nothing about the window itself, during which the document sits in plaintext, exposed to whatever happens to that server: a breach, a subpoena, a misconfigured storage bucket. These are unlikely events at any given moment, the same way any single email is unlikely to be in a breach. Multiply by every sensitive document a profession uploads in a year and the odds look different.

For regulated work, the judgment was never a personal one. A lawyer's confidentiality duty and a clinician's records obligations both treat "where did this document go" as a question needing a real answer. And if the document contains personal data, GDPR treats the upload as processing by a third party, which requires a written processor agreement under Article 28 and, when the server sits outside the EEA, a lawful basis for the transfer. "A free website, probably on AWS somewhere" will not satisfy an auditor.

Matching the tool to the document

None of this means you should never upload anything. Before you drop a file into any online tool, ask whether you'd email that same file to a stranger. For a concert flyer, a recipe or a public report, of course. Upload freely; the convenience is real and the risk is roughly nil.

For the other kind of document, the architecture matters more than the brand. This site exists because the upload step is now optional: browsers have become capable enough to run the whole toolchain locally, so the processing code is what travels, not the document. Compression, merging, editing: the file opens from your disk and the work happens in the tab, so no copy is ever written to a server. The same design is the reason there are no caps: ads in the page margins cover the hosting, and with your machine doing the work there is no per-file cost to recover on top.

How to test a tool's privacy claim yourself

"We delete your files" and "your files never leave your device" are both claims, but only one can be checked from your chair. Open your browser's developer tools, watch the Network tab while a tool runs, and see whether a request carrying your file goes out. Stronger still: run the tool once so it finishes fetching its own code, then disconnect from the internet and run it again. Local processing keeps working with the network gone; an upload-based tool stops immediately. The two-minute walkthrough shows what each outcome looks like, and it works on every PDF site, this one included.

One more habit for documents that matter, whatever tool touches them: author names, editing history and software traces ride along in the file's metadata no matter how the document is processed, and stripping that is its own job. Check it before you send.