Plenty of websites claim your files are private or secure. Far fewer explain precisely what has to be true, at an architectural level, for a "your files never leave your device" claim to actually hold up rather than just sound reassuring. It is worth spelling out, because the claim is checkable, not just a promise you have to trust.
The first requirement is the most basic one: the site has to be deployable as pure static files, with no backend server, no API endpoint, and no database anywhere in its production infrastructure to receive your file even if the client-side code tried to send it. minipdftoosz is built this way deliberately — it deploys to Cloudflare Pages as a static site, meaning the entire production deployment is HTML, CSS, and JavaScript files served over HTTPS, with nothing resembling a server-side application listening for uploads.
The second requirement is that every "processing" operation the site claims to do has to be implementable in code that runs inside the browser itself. This is where library choice matters enormously: pdf-lib, pdf.js, JSZip, signature_pad, markdown-it, html2canvas, and qpdf compiled to WebAssembly were all specifically chosen because each one is capable of doing real, correct PDF work using only JavaScript and WebAssembly — no server-side dependency anywhere in the chain. If a tool's core operation genuinely could not be done this way, the honest answer would be that the tool cannot exist on a zero-upload static site, not that it should quietly phone home to a server anyway.
The third requirement, and the one that is easiest to fake with words alone, is that no code anywhere in the shipped JavaScript actually issues a network request carrying your file data. This is the part you do not have to take on faith. Open your browser's developer tools (F12 or right-click, Inspect), switch to the Network tab, and use any PDF tool on this site while watching it. You will see the page's own static assets load once at the start — the HTML, CSS, JS, and vendor library files — and then, critically, nothing new fires when you select a file, process it, or download the result. No POST request. No fetch call carrying binary data. The absence of that traffic is the actual, verifiable evidence behind the claim, and it takes about thirty seconds to check for yourself on any tool page.
A related, honest caveat worth stating plainly: "no uploads" and "no external dependencies" are not automatically the same guarantee on every site that claims zero-upload processing. A site could genuinely avoid uploading your file while still loading its processing libraries from a third-party CDN, or embedding analytics scripts that phone home with metadata even if the file itself stays local. minipdftoosz avoids that gap too — every library is bundled locally with the site rather than fetched from a CDN at runtime, and the site's Content Security Policy is configured to only allow connections back to itself, which is enforceable at the browser level, not just a policy statement.
None of this requires trusting a company's privacy policy in the abstract. Static-only deployment, browser-executable processing libraries, absent network traffic during file operations, and a restrictive CSP are all facts about a specific build that you, or anyone with basic developer tools, can go verify directly. That verifiability is the actual point of building something this way, rather than the "trust us" version of the same promise.