Is there a PDF editor that does not upload your file?

What the usual promise means

Free online PDF tools are honest about their architecture if you read the page. Smallpdf states that files are removed from its servers one hour after processing; iLovePDF states that uploads are deleted within two. Both are reputable, both encrypt in transit, and neither claim is the one people think they are reading.

The claim is: a copy of your document was made on our infrastructure, and we delete it on a timer. Everything that can go wrong with a copy applies during that window — a misconfigured bucket, a backup that outlives the timer, a subpoena, an acquisition, a change to the policy next year. None of it is negligence. It is the unavoidable consequence of the file having gone somewhere.

A tool with no server has none of those failure modes, because it has no copy. That is not a stronger promise about handling. It is a smaller surface.

Why the browser can do the whole job

The work a PDF editor does turns out to be work browsers already do:

The job	What does it
Draw the page	pdf.js, rendering to a canvas
Read and write the form	pdf-lib, in a Web Worker
Find blanks on a printed page	Image processing on the rendered canvas
Read printed labels on a scan	OCR compiled to WebAssembly
Recognise fields on a form with none	An ONNX model, run on the device
Keep your details and signature	IndexedDB
Work offline	A service worker

None of that needs a round trip. The reason most tools have a server anyway is history: five years ago the detection and the OCR did not fit in a tab, and once a backend exists everything else moves onto it.

The architecture here is the consequence of that stopping being true. Detection and reading both fit, so the thing the server was for no longer needs one, and nothing in the core flow has anywhere to upload to.

What it does with the document

The file becomes an ArrayBuffer and stays one. The original bytes are kept untouched in memory, and every export starts from them again, so filling is never destructive and exporting twice gives you the same file twice. pdf.js renders the pages; the fields you type into are real HTML inputs positioned over the canvas, which is what makes tab order, IME input and screen readers work. pdf-lib rewrites the document inside a worker, so a 200-page file never stalls typing.

For a form that has no fields at all — a scan, a print-out, something typeset in 1954 — the page itself is read and the blanks are found, on the device, at 86% to 96% of the fields depending on how hard you ask it to look. Those numbers are scored against 41 published forms rather than asserted.

What it stores, stated plainly

• Your details — name, address, the things every form asks for — in IndexedDB, so autofill has something to match against. Matching is deterministic and local: a field name is reduced to its leaf, normalised, and scored against an alias table. No AI call, no network.
• Your signature, as a cropped PNG, in the same place.
• The answers you typed, keyed by a SHA-256 hash of the file, so reopening the same PDF offers them back. Storing the answers breaks no promise; storing the document would, so that one is yours to make — Keep the PDF too is off until you switch it on.
• The detector weights, in Cache Storage, if you ever download them.

There is no account, no telemetry on your documents, and no server-side record of any of it, because there is no server.

The one request

The trained detector is fetched once from a public CDN and kept in Cache Storage, ready for a form with no fields. That request carries no document and no identifier. It is started in the background when you open a PDF rather than when you scan, because otherwise the first scan is also the whole download — and it is skipped without asking on a connection the browser reports as metered or slow. It is a switch under Your details, and the geometry detector works with it off, forever, on a plane.

The PDF itself never leaves the tab, on any tier.