What uploading actually means
When you upload a PDF to an online tool, a copy of that file travels across the internet and is written to a computer belonging to someone else. Whatever the interface implies, that is the operation.
Several things follow from it, none of which are accusations. They are just what handing a file to a server entails:
- The file sits on disk somewhere, at least briefly, and disks get backed up.
- It passes through infrastructure you cannot see. Load balancers, storage layers, and logging systems are usually run by third parties, not the company whose name is on the site.
- Employees with production access can, in principle, read it. Whether they would is a question about their policies and their staff, not about the technology.
- It is now inside someone else's security perimeter. If they are breached, your document is part of what was breached, and you may never be told.
- It falls under whatever jurisdiction the servers sit in, which may not be yours.
None of this requires anyone to behave badly. It follows automatically from the file having been transmitted. The risk is structural.
The deletion promise
Every reputable service addresses this the same way: a promise that files are deleted after an hour, or a day, or immediately after processing. These promises are usually sincere.
They are also a different category of thing from an architectural guarantee, and the difference is the entire argument.
A policy is a statement about future intent. It depends on the code doing what the policy says, on the deletion job actually running, on backups being covered by it, on the company keeping the policy after its next funding round or acquisition, and on no incident occurring in the window before deletion. You cannot verify any of that from outside. You are being asked to trust, and trust is reasonable to extend, but it is not the same as not needing to.
An architecture that never transmits the file has nothing to promise. There is no retention window to get wrong, no deletion job to fail, no breach that can expose a document that was never sent. The guarantee is not stronger because the people are more trustworthy. It is stronger because there is less to trust.
How client-side editing works
Modern browsers can do far more than display pages. They can read files from your disk when you choose one, render complex documents, and write files back to your downloads folder, all without a server.
PDFree is built on that. Two well-established open-source libraries do the heavy lifting: pdf.js, which Mozilla built and Firefox uses as its own built-in PDF viewer, renders and parses the document; pdf-lib constructs the edited file. Both run as JavaScript in your browser tab.
When you choose a file, the browser hands the page a reference to it, and its bytes are read into memory in the tab. Every operation happens on that in-memory copy. When you save, the finished bytes are handed to the browser as a download and land in your downloads folder.
At no point in that sequence is there a request that carries your document anywhere. This is checkable rather than something you have to take on faith: open your browser's developer tools, switch to the network tab, and edit a document. You will see the site's own code and fonts load, and you will not see your file leave. If you want to be thorough, load the page, disconnect from the internet, and edit a PDF anyway. It works, because there was never anything for the network to do.
What PDFree stores, exactly
"Nothing is uploaded" is not the same as "nothing is stored", and it would be dishonest to blur them. Two things are kept, both in your own browser's storage, both on your device, neither ever transmitted.
The current file. The landing page and the editor are separate pages, so the PDF you opened has to survive the hop between them. It is written to IndexedDB, your browser's local database, as raw bytes. Clicking the home button in the editor deletes it. Opening a different file replaces it.
Your annotations. These are saved every few seconds, keyed by a hash of the document's contents, so if the tab crashes or you close it by accident, reopening the same file offers to restore your work. Annotations for the twelve most recently edited documents are kept and older ones are discarded automatically.
Both live in the same place as your browser's other site data, on your machine, under your control. Clearing your browser's site data for pdfree.pro removes them. The reason to explain this at all is that a claim of total statelessness would be false, and a privacy argument that requires a small lie to hold together is not one worth making.
What you can do without uploading
The obvious question is what this architecture costs in capability. Less than you would expect. Everything below runs entirely on your device:
- Redaction that genuinely removes text rather than covering it, by rebuilding affected pages and writing back only the text you kept.
- Filling and signing, both the PDF's own interactive fields and flat scanned forms that have none.
- Merging several documents into one, and splitting or extracting a page range back out.
- Optical character recognition, which is the surprising one. The recognition engine downloads to your browser and runs there, so even making a scan searchable does not require sending the scan anywhere.
- Rotating, reordering, deleting, and duplicating pages, plus inserting blanks.
- Compression and exporting pages as PNG or JPG.
- Bates numbering across a production, which matters precisely because the documents involved are usually the ones you least want on someone else's server.
The honest limits
A page arguing for one architecture should say where it loses.
Your device does the work. A server farm is faster than a laptop, and much faster than a phone. OCR on a long scanned document is the clearest example: it is genuinely slow, and that slowness is the direct price of the file not leaving. A server-based tool would finish sooner and would have your document.
Very large files can exhaust memory. Everything happens in a browser tab, which has finite memory. A few hundred megabytes of scanned pages can push a tab to its limit, especially on mobile. Servers have more room.
Some conversions genuinely favour a server. Heavy format conversion, such as turning a complex PDF into an editable word processor document, depends on tooling that is not practical to run in a browser today. If that is what you need, a server-based tool is the honest answer, and you should choose one that is clear about its retention policy.
You still have to trust the code. Trusting that a page does not upload your file is a smaller ask than trusting a company's retention policy, but it is not zero. The difference is that this one is verifiable: watch the network tab, or work offline. Very few claims about privacy can be checked in under a minute by the person making the decision. This one can. The source is public if you would rather read it than watch it.
Who this actually matters for
For a restaurant menu, none of this matters and anyone telling you otherwise is selling something. Use whatever is convenient.
It starts to matter when the document is one you would not email to a stranger. Employment contracts and offer letters. Tax returns. Medical records and insurance claims. Bank statements assembled for a mortgage. Legal filings under a protective order. Anything containing a national insurance or social security number, a full date of birth, or an account number.
It matters most when you are doing exactly the operations these tools exist for. Merging is how you assemble a complete set of financial records into a single file. Redaction is, by definition, something you do to a document containing information that must not be disclosed. Uploading at that moment means handing over the assembled, organised, sensitive version, which is worse than any individual piece of it.
The reasonable position is not that server-based tools are dangerous or that their operators are untrustworthy. It is that the upload is an unnecessary step for most everyday PDF work, and an unnecessary risk is worth removing when removing it is free. If you want the point-by-point version, the comparison page sets it out against the tools you have probably used.