Security architecture: where your file is processed
Not "your files are secure": the actual mechanism, the parts that are verifiable, and the limits of what anyone can promise you.
Two architectures, side by side
Most online PDF tools take your file, send it to a server, process it there, and send it back. This one does not. The difference is worth spelling out because it is the whole design:
- This site: your device → browser → PDF engine in the browser → new file → your download folder
- Upload-based tools: your device → someone's server → their processing → their storage → your download
The second list has a company in the middle holding your document, however briefly, under whatever retention policy applies. The first list has nobody. Your file does not need to leave your device, so it does not.
The specific claims, and what backs them
| Claim | Mechanism |
|---|---|
| The PDF is not uploaded | Processing runs in the page's own JavaScript. There is no upload endpoint and no API to send a file to. |
| The site can only load files from its own domain | The response header Content-Security-Policy: connect-src 'self' limits it to that. Every
other origin is blocked: a page on this site cannot send anything to a third-party server, which is what
the policy is there for. The policy carries ten directives, and two of them (default-src and
connect-src) are what keep the page from talking to anybody else. The one thing it does allow
is fetching the site's own PDF engine when you request
a rebuild or a preview. Nothing in the page ever transmits your document: the requests you can see are plain
GETs for static files. |
| No accounts and nothing retained | There is no sign-up, no cookie for identity, no server-side record of files. The tool holds your document in memory while the tab is open. |
| No analytics or third-party scripts | No tracking pixel, no ad network, no external font, no CDN-hosted script. Everything the page loads comes from the site itself. |
| The PDF engine loads only when needed | MuPDF WebAssembly (~10 MB uncompressed, ~4.4 MB over the network) is fetched when you request a rebuild or a page preview, and never on a normal page load. |
| Processing is not silently broken by the security policy | WebAssembly needs 'wasm-unsafe-eval' in the policy. It is present; without it, the rebuild
would fail with no visible error. |
Verify it yourself in sixty seconds
- Open the browser's developer tools and switch to the Network tab.
- Choose a PDF and run any operation.
- Watch the request list. You will see the site's own files: the page's script and stylesheet, and the engine if you asked for a rebuild. You will not see your document being sent anywhere.
- Stronger check: after the page has loaded, turn off your network connection and use the tool: scanning, removing and covering all keep working, because none of them needs the network. (A rebuild or a preview needs the engine to be fetched once; after that the browser has it cached.) A tool that uploaded files would fail immediately.
What this architecture does not protect you from
Honesty matters more here than reassurance. Local processing removes one risk (a third party holding your document) and it does not remove the others:
- Your own device. A shared computer, a synced download folder or malware on the machine sees exactly what you see. This site cannot change that.
- Browser extensions. An extension with permission to read page content can read your document. Review what you have installed, or use a private window with extensions disabled.
- The result you download. The cleaned file is a new file on your disk. Where it goes next is up to you and your sync settings.
- The site's own delivery. The pages are served by a hosting provider, which necessarily sees standard request information (IP address, user agent, the URL requested) for loading the page. It does not see your document, because your document is never part of a request.
Why this page avoids inflated security language
Because it would be meaningless. What can be described precisely: what runs where, what is blocked, what is stored, and how to check each of those claims. That is the standard this page holds itself to, and it is why the privacy policy is short enough to read.