What happens when you upload a PDF online

Arif Shakil — Sun, 09 Aug 2026 08:30:40 +0000

Disclosure: I build UMyPDF, a browser-based PDF toolkit, which comes up at the end of this post. The explanation applies to any tool built either way, and the check in the second-to-last section works on mine as well as anyone else's.

You have a PDF that needs to be smaller. You search for a way to do it, click the first result, drag the file onto a friendly dashed rectangle, and a few seconds later you download a smaller PDF. The whole thing takes under a minute and it works.

The part nobody mentions is what happened in between. On most free PDF sites, that file left your computer, travelled across the internet, landed on a machine belonging to a company you had never heard of ninety seconds earlier, and was written to a disk there. The compression happened on that disk. Then the result travelled back.

That step is not a scandal. It is just how those tools are built, and for a lot of documents it genuinely does not matter. But it is invisible, it is the default, and most people would make a different choice about some of their documents if they knew it was happening. So here is what it actually involves.

The upload nobody mentions

A PDF tool has to run its code somewhere. For most of the last twenty years, "somewhere" meant a server, because browsers could not do the work — parsing a PDF, re-encoding its images, running OCR over a scan. Those were desktop-software jobs.

So the standard design is: take the user's file, send it to a machine we control, do the work there, send the result back. The dashed rectangle you drag onto is a file input wired to an HTTP request. Every "free online PDF" tool built this way is, structurally, a file-hosting service that happens to hand you something back.

This is why the wording on those sites is worth reading closely. "Your files are safe with us" and "your files never leave your device" are very different promises, and only one of them is about where the file goes.

Where the file actually sits

Once the upload completes, your document typically exists in more places than the one you were told about:

On the processing server's disk, at least for the duration of the job. Many tools write the input, the intermediate, and the output as three separate files.
In object storage, if the service is built to scale — which almost all of them are. The upload endpoint and the machine doing the work are usually not the same machine, and the thing joining them is a storage bucket.
In backups and snapshots of that storage, which is a thing storage providers do automatically and which operates on its own retention schedule.
In logs, not usually the file contents, but the filename, size, your IP address, and the timestamp. Filenames alone can be remarkably revealing: Settlement_Agreement_Draft_v4.pdf tells a story before anyone opens it.
On a CDN, if the download link is served through one, which caches the result at edge locations around the world.

None of this requires anyone to be acting in bad faith. It is the ordinary architecture of a web service. The point is only that "we delete your files" is a claim about one of these copies, and the honest version of that sentence is longer than it usually gets written.

What "files deleted after one hour" really covers

This is the industry-standard reassurance, and it is doing less work than it appears to.

It is a claim about retention, not about exposure. During that hour, the file is a normal object in a normal storage system, reachable by whatever has credentials to that system — the application, the operations team, the storage provider, anyone who has obtained a credential they should not have, and any legal process served on the company. Deletion at the end of the hour does not retroactively change any of that.

It also says nothing about the download link. On several popular tools, results are served from a URL that is unguessable but not authenticated — anyone holding the link can fetch the file, and links travel: into chat messages, into browser sync, into corporate proxy logs.

And it is a claim you cannot verify. There is no way, from outside, to confirm that a deletion job ran, that it covered the backups, or that the hour was an hour. You are being asked to trust a promise about the inside of a system you cannot see. That is a perfectly normal thing to be asked, and people extend that trust to their bank every day. It is just worth noticing that you are extending it to compress a PDF.

Why PDFs are a bad category for this

A PDF is rarely a neutral file. Think about what is actually in the ones on your machine right now: signed contracts, medical letters, bank statements, passport scans for a visa application, a tenancy agreement, tax returns, a CV with your home address and phone number on it.

PDFs also carry more than they display. Metadata routinely includes the author's name, the software and machine that produced it, and creation and modification timestamps. Documents assembled from other documents can retain earlier revisions in the file structure. A "flattened" scan may still have a full text layer. Redactions applied as a black rectangle on top of the text leave the text sitting underneath it, fully selectable — this has embarrassed law firms and government departments repeatedly, in filings that were genuinely reviewed by careful people.

So the file you upload to make smaller is often carrying substantially more than the page you were looking at.

The other way: do the work in the browser

The reason any of this can change is that the constraint disappeared. Browsers got fast, and the specific technologies that made desktop PDF software possible now run inside a tab:

WebAssembly runs compiled code — the same C and C++ libraries that power desktop PDF tools — at close to native speed, inside the browser's sandbox.
Web Workers run that code on a background thread, so a 200-page document does not freeze the page while it is processed.
Mature JavaScript libraries — pdf.js (Mozilla's renderer, the one built into Firefox), pdf-lib for writing and editing, Tesseract.js for OCR — handle parsing, rendering and modification with no server involved.

When a tool is built this way, the dashed rectangle is not a file input wired to an upload. It is a file input wired to a FileReader. Your document is read into the tab's memory, worked on there, and written back out as a download. It never becomes an HTTP request body. There is no server copy to retain, because there was never a transfer.

The honest trade-offs: the work uses your device's CPU and memory, so a very large file is slower on an old laptop than it would be on a rented server. The first visit downloads more code than a thin upload page would. And there are a small number of genuinely heavy jobs where a server would win on raw speed. For the overwhelming majority of everyday PDF work — merging, splitting, compressing, converting, rotating, signing — the difference is a second or two, and you get to skip the entire question of what happens to the file afterwards.

How to check any tool yourself

You do not have to take anyone's word for this, including ours. It takes about thirty seconds in any desktop browser.

Open the PDF tool you want to test, but do not add your file yet.
Press F12 to open developer tools, and select the Network tab.
Tick Preserve log, so navigation does not clear the list.
Now add your file and run the tool.
Sort the request list by Size, largest first.

If your document was uploaded, you will see it plainly: a POST or PUT request whose payload is roughly the size of your file. Click it and the Payload or Request panel will show the file being sent. There is no way to hide this — it is the browser reporting its own outgoing traffic.

If the tool runs locally, the largest requests will be the code and assets the page needed to load, and nothing leaves after you add your file.

Run this on two or three tools you have used before. It is a genuinely clarifying thirty seconds.

Where we stand

UMyPDF is built the second way. Every tool on the site — compressing, merging, splitting, converting, OCR, signing, redacting — runs in your browser. Your document is not uploaded, because there is no upload step to reach. You can confirm that with the Network tab check above, and we would rather you did than took our word for it.

There is exactly one deliberate exception, and it is worth naming rather than burying. If you explicitly choose to create a share link for a result, that file does get stored, because a link that another person can open has to point at something. In that case the file is encrypted in your browser before it goes anywhere, using a key that lives only in the fragment of the link — the part after the #, which browsers never send to the server. We hold the ciphertext and cannot read it. Nothing creates a share link unless you ask for one.

Everything else stays on your machine, which is where a signed contract or a medical letter should probably have been all along.

More on the technical side of this on our security page, and the full detail of what is and is not stored in the privacy policy.

DEV Community: Arif Shakil