"Files never leave your browser" is becoming standard copy for PDF tools, image editors, and document converters. But a trust claim and a verifiable fact are different things. Here's how to turn "zero upload" into something any user can audit in about two minutes, and how to enforce it at the browser level so it isn't just a promise.

Step 1: Read the Network panel

Open DevTools → Network, enable "Disable cache", reload. While processing a file, filter by "Fetch/XHR" and "Doc". A genuinely client-side tool should show only HTML/CSS/JS/WASM asset loads — no POST requests, no GETs carrying file content in query parameters.

The non-obvious trap: third-party analytics, Google Fonts, and CDNs all show up as outbound requests. If you claim zero uploads, those count too. The honest move is to self-host fonts and scripts and drop analytics entirely, so the request list is genuinely short enough to eyeball.

The Network panel is the human-readable check. The next part is what actually makes it hold.

Step 2: Enforce egress with CSP connect-src

This is the piece people get backwards, so it's worth stating precisely.

CSP's connect-src is an egress allowlist the browser enforces before the request is sent. A fetch/XHR to an origin that isn't on the list is blocked by the browser and never leaves the machine. You'll see it fail in the console as a CSP violation, with no entry in the Network tab going out to that origin.

This includes no-cors requests. no-cors is sometimes assumed to be an escape hatch, but it isn't one for this purpose. All no-cors does is let you issue a cross-origin request while making the response opaque (you can't read the body). It does not bypass connect-src: if the target origin isn't in your connect-src allowlist, the no-cors request is blocked exactly the same way — it never goes out. So you can't smuggle a file out to a third party with no-cors under a tight CSP.

That's what makes CSP the actual proof, not just documentation. Tighten connect-src to 'self' (or an explicit list of the few endpoints you genuinely need), and any code path that tries to ship data to another origin — yours, a third party's, an injected script's — is stopped by the browser. A realistic policy:

connect-src 'self';
font-src 'self';
script-src 'self' 'wasm-unsafe-eval';
img-src 'self' data:;

Note 'wasm-unsafe-eval' rather than the broader 'unsafe-eval' — modern browsers support the narrower directive for instantiating WASM, so there's no reason to grant full eval.

With that in place, the Network panel check from Step 1 stops being "trust me, the list is short" and becomes "the browser will refuse to send anything I didn't whitelist, and here's the empty list to confirm it."

Step 3 (optional): Content-Length as a sanity check

If you want a quick gut-check rather than reasoning about the allowlist, clear the Network panel before triggering processing, then sum the Size column afterward. If the total is nowhere near the original file size, no file content went out. This also catches chunked-transfer or WebSocket approaches that a naive "look for a POST" scan might miss. It's a weaker check than the CSP guarantee, but it's fast and visual.

A Service Worker doesn't replace CSP

A Service Worker can intercept fetches and is useful for offline caching, but it's not the egress boundary — it's first-party code that can be bypassed or simply not cover a code path, and it does nothing about requests that don't route through it. CSP connect-src is enforced by the browser regardless of your application code. Use a Service Worker for caching if you want; rely on CSP for the "can't exfiltrate" guarantee.

What this looks like in practice

I built a PDF tool this way (moguanpdf.com, my own project — mentioning it only because it's a live example you can poke at). The classic tools (compress, merge, split, OCR, watermark, encrypt/decrypt, etc.) run entirely in-browser via WASM + pdf.js. Open DevTools → Network while processing a file and you'll see only .wasm, .js, and .css loads, no POST, no analytics. The one server-side exception is the AI features (summarize/translate/Q&A), which send extracted text rather than the file, and the UI says so. I'd encourage auditing it the same way you'd audit anyone else's — that's the whole point.

The broader point

If your users handle contracts, medical records, or financial documents, "open DevTools and follow these steps, and here's the CSP that guarantees it" is a stronger statement than any privacy policy. The Network panel shows users an empty list; connect-src 'self' is the reason the list stays empty. A tool that can't survive that audit probably shouldn't be making the claim.