How to verify a “private” tool really uploads nothing

Published 2026-07-29

“Your files never leave your device” is the easiest sentence in software to write and one of the easiest to check. Almost nobody checks it. Here are four tests, in ascending order of effort, that you can run on this site or any other before you trust it with something that matters.

Run them on us. That is the point of writing this down.

Test 1: pull the plug (10 seconds)

Turn off Wi-Fi, or switch on airplane mode. Load the tool — or reload it if it is already open — and use it.

A genuinely local tool keeps working. A tool that sends your data somewhere either fails outright, hangs on a spinner, or shows an error. There is no third option: if the processing happens on a server, no server means no processing.

Two caveats so you read the result correctly. First, the page has to have loaded at least once before, or there is nothing in the browser cache to run. On this site the service worker caches the page and its scripts on the first visit, so a reload with the network off works from then on. Second, some sites will appear to work offline while quietly queuing an upload for later; test 2 catches that.

Test 2: watch the network tab (60 seconds)

Press F12 (or Cmd+Option+I on a Mac) and open the Network panel. Reload the page so you see everything, then use the tool: paste your text, click the buttons, download the result.

What you are looking for:

• Any POST, PUT or PATCH request. Those are how data is sent to a server. A local tool makes none, ever. GET requests for the site’s own scripts, fonts and icons are normal.
• Requests to a domain that is not this site. A CDN fetch for a library is not automatically sinister, but a request to an API domain while you are processing data is.
• Large request payloads. Click any suspicious request and look at the size and the payload tab. A 2 MB request going out while you convert a 2 MB file tells its own story.

This site makes zero non-GET requests, ever. The scrubber also shows you a live counter in its toolbar — “network while you type” — that counts every resource the page requests once you start typing, using the browser’s own PerformanceObserver API. It stays at zero, and it is not our measurement: it is your browser’s.

Test 3: read the page source (2 minutes)

Ctrl+U shows you the HTML. view-source: works on the JavaScript files too, and the Sources panel in DevTools lets you read them formatted.

You do not need to understand all of it. Search (Ctrl+F) for a few strings:

• fetch( and XMLHttpRequest — the two ways JavaScript sends data. Find them, and read what they send. A site fetching its own static files is fine; a site fetching your input is not.
• FormData — commonly used to build an upload.
• sendBeacon — a way to send data that survives the page closing.
• <form with an action attribute pointing somewhere off-site.

On a static, local-only site these searches turn up nothing that touches your input. Modern frameworks generate a lot of code, so the honest version of this test is “search for the dangerous verbs”, not “read everything”.

Test 4: check the response headers (5 minutes)

In the Network panel, click the document request and read the Response Headers. A tool that is serious about this will ship a Content-Security-Policy that restricts where the page is allowed to send anything — a connect-src limited to its own origin means the browser itself will block an upload attempt, even if the code tried.

That is the difference between a promise and an enforcement. A privacy policy is a statement of intent; a CSP is the browser refusing to cooperate.

What the tests cannot tell you

Be clear-eyed about the limits.

They test this visit. A site could serve different code tomorrow, or to a different visitor. The mitigations are habit (spot-check occasionally) and architecture: a static site with no backend has nowhere to send data to even if it wanted to, and a Content-Security-Policy in the response headers is checkable on every load.

They do not test the browser or the extensions. An extension with permission to read every page sees what you type regardless of how the page behaves. This is a real argument against the browser-extension category of redaction tools: to redact what you paste anywhere, an extension needs to read everything you visit.

They do not audit correctness. A tool can be perfectly local and still miss half the personal data in your document. Local processing is a privacy property, not a quality one. Which is why the detector list on this site says what each detector misses, and why the scrubbed text is highlighted rather than silently swapped.

Why architecture beats promises

The reason to prefer local tools is not that hosted services are dishonest. It is that a hosted service can change its mind — new owner, new investors, a pivot, a subpoena — and you would not know. A static site with no upload endpoint cannot change its mind quietly, because the change would be visible in the network tab of every user who looked.

That is the standard worth applying to any tool handling something sensitive: not “do they promise not to look”, but “are they structurally unable to”. Then spend a minute confirming it, on this site as much as anyone else’s.