What actually happens when you upload a PDF to a converter site

Where the file actually goes

Drag a PDF onto a typical converter site and the browser opens a connection and streams the bytes to a server. That server writes the file to a disk, because command-line PDF tools work on paths, not on streams. Something then runs against that path: Ghostscript, qpdf, ImageMagick, LibreOffice, whichever fits the job. The output is written next to it, a link comes back to you, and a cleanup job is supposed to delete both some time later.

Every step there is ordinary engineering. Nothing about it is sinister. But by the time you see the download link, your document has been written to a disk you do not control, in a jurisdiction you probably did not check, and read by software running as some user on a shared machine.

The retention promise

Most sites say files are deleted after an hour, or a day. That is usually true, and it is worth noticing what kind of claim it is. It is a promise about a scheduled job continuing to work correctly, on infrastructure you cannot see, operated by people you will never meet, for as long as the company exists.

Backups complicate it further. A file deleted from the live disk at the one-hour mark can still be sitting in a nightly snapshot for weeks, because snapshots are taken of the whole volume and nobody reaches into them to remove one temporary upload. That is not a scandal, it is just how backups work, and it is rarely what people picture when they read the sentence about deletion.

The bug class nobody mentions

There is a specific failure that keeps recurring in server-side PDF handling, and it is worth understanding because it explains a lot about how this site is built.

To do the work, the server has to hand your file to another program. The lazy way to do that is to build a command as a string and let the shell run it. If the filename you uploaded ends up inside that string without being escaped, then the filename is no longer just a name. Characters like a semicolon end one command and start another, and the second one runs with whatever permissions the web application has.

The predecessor of this project had exactly that. It shelled out to a PDF utility with a user-supplied filename, unauthenticated, on every conversion. Anyone who could use the site could run commands on the box holding everybody else's documents. It is a well-known category, it has a name, and it still ships regularly.

⚠️The fix for that one bug is a single line: pass arguments as an array instead of building a shell string. The fix for the category is to not have a server in the path at all.

What the browser can do instead

The interesting thing is that the whole pipeline stopped being necessary. Browsers can read a file off your disk, parse a PDF, render pages to a canvas, rewrite the document structure and hand you a new file to save. Mozilla's pdf.js has been doing the reading part inside Firefox for over a decade.

So for merging, splitting, rotating, reordering and converting to images, the server is doing work your own machine could do. Remove it and a list of problems disappears at once:

• No retention policy to trust, because nothing was ever stored.
• No breach exposure, because there is no pile of other people's documents to breach.
• No command injection, because no server-side program is being handed your filename.
• No jurisdiction question, because the file never crossed a border.

Where it does not work

Being straight about the limits: converting Office documents faithfully needs something like LibreOffice, which is not going in a browser tab any time soon. Some compression tricks want tools that do not exist in JavaScript. Good OCR is heavy too, though in October 2026 it turned out not to be too heavy: OCR PDF here reads scanned pages on your device, after a download of a few megabytes the first time.

The first two genuinely need a server, and a site that offers them is not doing anything wrong by having one. The mistake is running a server for jobs that do not need it, which is most of them, and then asking people to trust a deletion policy they had no reason to need.

How to tell which kind you are using

Open the tool, wait for it to finish loading, then turn off your wi-fi and use it. If it still works, the processing is local and nothing was ever going to be uploaded. If it fails, the file was going somewhere.

That test takes ten seconds and it works on any site, including this one. How PDFsansar works goes through the mechanics, and the security page covers what is left to attack when there is no server.