Every day, millions of people drag sensitive documents into online PDF tools without thinking about where those files actually go. Contracts, tax returns, medical records, legal filings — uploaded to servers owned by companies most users know nothing about, processed in environments they cannot inspect, and retained under terms they never read.
This is the default model for the PDF tools industry. It should not be.
How Smallpdf, iLovePDF, and Adobe handle your files#
When you upload a PDF to Smallpdf, your file is sent to their servers for processing. Smallpdf states that files are deleted after one hour for free users and that they use TLS encryption during transfer. That means your document sits on their infrastructure for up to sixty minutes. If you use the free tier, Smallpdf also limits your daily usage — meaning they are tracking you across sessions.
iLovePDF follows a similar pattern. Files are uploaded to their servers, processed remotely, and — according to their privacy policy — deleted after a set period. They operate servers in Europe and comply with GDPR, which is better than nothing, but the fundamental architecture is the same: your files leave your device.
Adobe Acrobat Online uploads files to Adobe’s cloud infrastructure. Adobe’s terms grant them broad rights to process uploaded content, and their enterprise-grade infrastructure means your document passes through multiple systems during processing. Adobe has also faced repeated controversy over its subscription practices — early termination fees buried in fine print, dark patterns that make cancellation deliberately difficult, and a 2024 update to their terms of service that appeared to grant Adobe the right to access user content for AI training, which provoked enough backlash that the company was forced to walk it back. The FTC has taken notice. For a company that invented the PDF format, Adobe has become more interested in extracting recurring revenue from it than in serving users well.
In all three cases, the architecture requires your files to leave your machine. Once they do, you are trusting the provider’s security practices, their employee access controls, their data retention policies, and their compliance with whatever privacy laws apply to their jurisdiction.
Client-side PDF processing: how it works and why it matters#
There is no technical reason a PDF merge, split, compression, or conversion needs to happen on a remote server. Modern browsers are powerful enough to handle these operations locally. JavaScript can parse PDF structures, manipulate page trees, compress images, render text, and even perform OCR — all within the browser tab.
Client-side processing means the file never leaves your device. There is no upload, no server-side storage, no retention window, no access control to worry about. The processing happens in browser memory, the output is generated locally, and when you close the tab, everything is gone.
This is not a theoretical distinction. You can verify it yourself. Open your browser’s developer tools, switch to the Network tab, and watch what happens when you process a file. With a server-side tool, you will see a large upload request. With a client-side tool, you will see nothing — because the file never leaves.
PDF privacy risks for legal, medical, and financial documents#
For casual use — rotating a page, merging two documents — the privacy risk of server-side processing is low. But the same tools that handle casual tasks also handle sensitive ones, and users rarely switch tools based on the sensitivity of the document.
Lawyers merge case files containing privileged communications. Accountants compress tax returns with social insurance numbers. HR departments convert offer letters with salary details. Medical professionals split patient records. In each case, uploading the file to a remote server introduces risk that simply does not need to exist.
The European Union’s GDPR and Canada’s PIPEDA both impose obligations on how personal data is processed and transferred. Uploading a document containing personal information to a server in another jurisdiction can create compliance exposure — especially for organizations that have not specifically vetted the tool’s data processing agreements.
Why PDF tools use server uploads: subscriptions and control#
The reason most PDF tools upload files to servers is not technical — it is economic. Server-side processing lets providers meter usage, enforce subscription tiers, and track engagement. If the browser does the work, there is nothing to meter. The tool is either available or it is not.
This is why most server-side PDF tools offer a limited free tier and then push you toward a subscription. The server is the control point. Remove the server, and the business model based on restricting access to basic file operations falls apart.
Client-side tools can be hosted on static infrastructure for nearly nothing. The browser does the computation. The server just delivers the HTML, CSS, and JavaScript. There is no file processing cost, no storage cost, and no reason to restrict usage.
PDF Pony: 145 tools that never touch a server#
PDF Pony runs 145 PDF tools entirely in the browser. Every operation — from basic merges to cryptographic digital signatures with full PKI support — processes locally. Files exist only in browser memory for the duration of the operation. There are no accounts, no subscriptions, no watermarks, and no file upload requests to intercept.
I built it because the existing options asked users to choose between capability and privacy. That should not be the tradeoff. The browser is powerful enough to do this work. The question is whether the developer’s business model is aligned with the user’s interests — or opposed to them.
