Privacy
Why You Should Never Upload Your PDFs to a Website
April 2026 · 7 min read
What actually happens when you upload
When you drag a PDF onto an online tool and click a button, your file travels over the internet to a server operated by that company. It is stored on their infrastructure while the operation runs, and it stays there for some period of time after. The company has access to every byte of your document.
This is not inherently malicious - it is just how server-side processing works. The company needs your file on their server to process it. But it means that a document you considered private is now in someone else's possession, even temporarily.
The duration of that possession varies. Some services delete files within a few hours. Others retain them for days. A few have policy language vague enough that it is unclear how long files persist or who else within the organization might access them.
What the data retention policies actually say
ILovePDF's policy states that files are deleted from servers after two hours. Smallpdf deletes files after one hour by default, with options to extend. These are the industry-standard timeframes and they are probably accurate for the actual files - but the policies also typically allow the company to retain aggregated usage data and metadata about your uploads.
The more important question is what happens during that window. Your file is on a server that is accessible to the company's employees, contractors, and systems. It is also potentially accessible to anyone who exploits a vulnerability in their infrastructure. In 2021, one major online PDF service experienced a data breach that exposed user files and email addresses.
Reading the full terms of service for these tools is instructive. You will typically find language giving the service a licence to process your content for purposes including service improvement. The practical implications of that language are rarely spelled out.
Which documents are actually at risk
Most PDFs people process are low-sensitivity. Uploading a user manual or a publicly available form carries no meaningful privacy risk. The concern is with documents that contain information you would not want a stranger to read.
Contracts are the clearest case. NDAs, employment agreements, and client contracts frequently contain commercially sensitive terms, salary figures, and proprietary information. Uploading these to a third-party server exposes information that parties to the contract intended to keep confidential.
Medical records, lab results, and insurance documents contain health information that is legally protected in most jurisdictions. Financial statements - tax returns, bank statements, investment account summaries - contain information that is directly useful to identity thieves. Even a simple invoice reveals your client relationships and pricing. The question to ask before uploading is: would I be comfortable emailing this file to a stranger? If the answer is no, an upload-based tool is not the right choice.
How browser-based processing works differently
Browser-based PDF tools use WebAssembly - a binary instruction format that runs at near-native speed inside the browser sandbox. Libraries like pdf-lib, compiled to WebAssembly, can read, modify, and write PDF files entirely within your browser's memory. The file never needs to leave your device.
When you use a tool on PDFsuite, your PDF is loaded into memory in your browser tab. The processing runs on your own CPU. The output is written back to memory and downloaded to your machine as a file. At no point does any network request carry your PDF data.
This is not a policy promise that could be changed by a new privacy officer. It is architectural. A server-side tool cannot choose not to receive your file - that is its entire operating model. A client-side tool cannot transmit your file even if it wanted to, because the processing code runs in a sandbox with no server to send data to.
How to verify no upload in DevTools
You do not have to take this on faith. Browser developer tools let you inspect every network request a page makes. Open Chrome or Firefox, press F12 to open DevTools, and click on the Network tab. Now use PDFsuite to process a file.
Watch the network requests. You will see requests for static assets - JavaScript, CSS, fonts - and potentially requests to the authentication service (InstantDB). You will not see any request that transmits your PDF data. The file sizes in the requests column will not correspond to the size of your PDF.
If you do the same test with an upload-based tool, you will see a POST request whose payload size matches your PDF. That is your file leaving your device. The difference is visible and verifiable in about thirty seconds.
Practical advice for document handling
For sensitive documents, make browser-based tools your default. For clearly low-risk files - public forms, marketing materials, content you would post publicly anyway - upload-based tools are probably fine and convenient.
If you must use an upload-based tool for a sensitive document, check the retention policy, use a service that offers explicit deletion, and avoid tools with vague or absent privacy documentation.
Consider the full chain of custody. If you merge a contract, compress a medical record, and convert a financial statement all using the same online tool, you have given that service access to a fairly comprehensive picture of your affairs. The aggregated exposure is greater than any single upload.
Try it yourself
Process your PDFs in the browser.
All 28 tools. Files never leave your device. $29/year.