What happens to your file when you use an online PDF tool
Last updated: 2026-07-27
You need to drop a signature onto a contract, and you need it done in the next five minutes. So you search for a free PDF tool, upload the file, download the result, and move on. It works. But there is a question worth asking once, and then never having to ask again: where did that file actually go?
What an upload-based tool really does
Most online PDF tools process files on a server. The sequence is roughly this. Your browser uploads the file over HTTPS. The server writes it to disk or to object storage as a temporary file. A program running on that server — Ghostscript, qpdf, or a commercial PDF engine — opens the file, performs the operation, and writes a new file. The server then hands you a download link.
The word doing a lot of quiet work in that description is temporary. Your original, any intermediate artifacts, and the finished output all land on disk. That disk is usually part of an automated backup schedule. Web server logs record the filename, your IP address, and a timestamp. If the download link is served through a CDN, an edge cache may hold a copy too. Uploading one file rarely produces exactly one copy of it.
How much can you trust “files are deleted after one hour”?
Plenty of services promise that uploads are permanently deleted within an hour, and most almost certainly mean it. The difficulty is that you have no way to confirm it. Whether the deletion job actually ran, whether the file was purged from last night's backup snapshot, whether the filename still sits in a log aggregator — all of that happens inside infrastructure you cannot see. It is a promise, not a technical guarantee. Honest companies keep it; they just cannot demonstrate that they kept it.
And during the window before deletion, the file genuinely exists on someone else's computer. If that server is breached in that window, your document is part of the breach. If the operator receives a lawful subpoena or preservation order, your document is within scope, under whichever country's law applies to them. For a restaurant menu, none of this matters. For an unsigned term sheet, it might matter a great deal.
There is a compliance dimension too. Under the GDPR, a service that receives your file is processing personal data on your behalf, which normally calls for a data processing agreement, a defined retention period, and disclosure of transfers outside the EEA. Free consumer tools rarely offer any of that.
The other approach: processing in the browser
The alternative is to ship the PDF code itself — as JavaScript or WebAssembly — down to the browser, and do all the work on the user's own machine. In that model the server sends you a program; you never send it a document. There is no uploaded file to retain, so there is no retention policy to trust and no deletion promise to verify.
Three ways to check any tool yourself
Do not take a marketing page's word for it. Check.
1. Open the Network tab. Press F12 (or Cmd+Option+I on a Mac) to open developer tools, switch to Network, then load your PDF and run the operation. A server-side tool will show a request roughly the size of your file — a multi-megabyte POST or PUT. Turn on the Fetch/XHR filter to see it clearly. A browser-side tool shows the initial page and script downloads and then goes essentially quiet.
2. Disconnect from the internet. This is the most convincing test and requires no technical knowledge. Load the page fully, then turn off Wi-Fi, or tick Offline in the Network tab. Now try to do the work. If you can still open the PDF, place your image, and save the result, the processing code is already running locally and nothing is being sent anywhere. A server-based tool simply stops at this point.
3. Read the privacy policy. Boring, but it takes five minutes. Look for upload retention periods, third-party sub-processors, and international transfers. A genuinely client-side tool usually states plainly that it does not collect your files.
For what it is worth, StickPDF runs pdf-lib and pdf.js directly in the browser, so all three checks come out the same way. That is a claim you can verify in under a minute rather than take on faith — which is the point.
Server-side is not the villain
None of this means server processing is inherently bad. Plenty of work genuinely belongs on a server: OCR needs recognition models far too large to download, batch jobs across hundreds of files need real compute, and anything integrating with a document management system is server-side by definition. Browsers also have memory limits, so a 500 MB scanned archive is a poor fit for client-side handling.
The useful question is not “server or browser?” but “does this approach match the sensitivity of what I am holding?” For a public brochure, either is fine. For an unsigned contract, HR records, or pre-release financials, a tool that never transmits the file removes an entire category of risk at no cost. Many organizations also prohibit uploading internal documents to unvetted web services at all, so check your own rules before your tool's. And when you do need a server-side service, confirm the operator is identifiable and that retention and sub-processors are documented specifically rather than vaguely. Thirty seconds of checking, once per tool, is the whole discipline.