Home / How it works
How it works, and why nothing is uploaded
Modern browsers can parse and write PDF files on their own using JavaScript. This editor loads two open source engines — PDF.js to read and render, pdf-lib to write — and runs them on your machine. Because the work happens where the file already is, there is nothing to upload and no server that could receive your document.
Every online PDF tool follows the same shape: your file goes up, a server does the work, a result comes back. That shape is not a choice about privacy. It is a choice about where the CPU cycles are spent, and everything else follows from it — the metering, the accounts, the subscriptions, the retention policy you have to trust.
The alternative has been available for years and is oddly under-used: run the same libraries in the browser instead.
What happens when you open a PDF here
Five steps, none of which involves a network request.
Your browser reads the file
Choosing a file gives the page a reference to bytes on your own disk. The browser reads them into the tab's memory. This is a local file read, not a transfer.
PDF.js parses and renders it
Mozilla's PDF.js — the same engine built into Firefox — parses the document structure and draws each page onto a canvas. It runs in a background worker so the interface stays responsive.
Your edits are held as a description
Stamps, text and shapes are stored as a list of objects with positions, not as changes to the file. The bytes you opened are never modified, which is what makes Safe Mode structurally true rather than a promise.
pdf-lib writes a new document
On export, pdf-lib copies the pages you kept, applies rotations, draws your objects into the page content, and serialises a brand new PDF in memory.
The result is checked, then saved
Before you are told it worked, the new file is reopened by PDF.js, its page count is compared, text extraction is re-run and the structure is re-parsed. Only then does your browser save it to your downloads folder.
Why the privacy claim is worded carefully
We say your documents never need to be uploaded. We do not say "zero bytes are transferred", because the application itself has to reach your browser once — and a claim you can disprove in thirty seconds is worse than no claim.
The precise position is: page and asset requests happen, like on any website; document requests never do, because they do not exist.
Four ways to check it rather than believe it
- The network tab. Open developer tools, load a PDF, edit it, export it. After the app files finish loading there is no further traffic.
- The Content Security Policy. This site sends
connect-src 'self'. Your browser refuses cross-origin transmission at the platform level, regardless of what our JavaScript attempts. The privacy property is enforced by the browser, not by our intentions. - Pull the plug. Load the page, disconnect from the internet, keep working. Anything that needed to send your file somewhere could not do this.
What the browser is actually good at
| Task | In the browser |
|---|---|
| Rendering pages | Excellent. Hardware-accelerated canvas, sharp on high-density screens. |
| Page operations, merge, split | Excellent. Structural work on the object tree, fast even on hundreds of pages. |
| Stamps, annotations, form filling | Excellent. No round trip means the preview updates as you type. |
| Batch processing a folder | Very good, and free — it costs us nothing because it runs on your CPU. This is the feature every hosted tool puts behind a paid tier. |
| OCR of scanned pages | Possible with a WASM engine, but the models are large. Not shipped yet, and it will be an optional download when it is. |
The limits, stated plainly
Your device does the work, so your device sets the ceiling. A 2,000-page scanned document will strain a phone. Very large batches are bounded by available memory, which is why files are released as each one finishes. And editing the original body text of a PDF is not supported here at all — not because of the browser, but because doing it reliably is beyond what any tool manages without damaging layout, including the most expensive desktop editors.
Try it — there is nothing to sign up for.
Open the editor and drop a PDF in. Your file stays on your device, and you can take the whole thing offline whenever you want.
Straight answers
Which libraries does it use?
PDF.js (Apache 2.0) from Mozilla for reading and rendering, pdf-lib (MIT) for writing, and fflate (MIT) for creating ZIP archives during batch runs. All three are bundled with the app and served from this domain — nothing is fetched from a third-party CDN at runtime.
Is my data safe if the website is compromised?
A compromised static site is a real risk for any web app, which is why the defences are layered: the Content Security Policy blocks cross-origin transmission, the app refuses outbound requests carrying a body, and the editor permits no third-party origin at all. For the strongest position, download the single-file build and run it from your own disk — then there is no website in the loop at all.
Why is this free when every other tool charges?
Because the expensive part of a PDF service is CPU time on servers, and we do not spend any. Serving static files to a lot of people is cheap. There is no free tier here because there is no paid tier to protect.
Can I host it myself?
Yes, and you are encouraged to. It is a folder of static files — put it on an intranet server, or drop the single HTML file on a network share. Many organisations prefer this because it works with no outbound connection whatsoever.