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. |
| Your document cannot leave through the page | The response header Content-Security-Policy lists the origins the page may talk to. Since
Google AdSense was added on 1 November 2026, that list includes Google's advertising domains, so the page
can load ads. It still contains no endpoint that accepts a file: processing runs in the page's own
JavaScript and there is no upload URL to send anything to. The only same-origin fetch is the site's own PDF
engine when you request a rebuild or a preview. Nothing in the page ever transmits your document. |
| 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 tracking scripts | No tracking pixel, no external font, no CDN-hosted library, no analytics. The one third-party script is Google AdSense, added 1 November 2026 to fund the site; it loads from Google's domains and may set advertising cookies. Your document is never visible to it. |
| 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.