Why the detection runs in your browser, and how to verify it

There is an obvious flaw in the idea of an online redaction tool: to remove secrets from your text, it has to see your text.

If that inspection happens on a server, you have solved nothing. You were worried about sending sensitive text to one third party, and the remedy was to send it to a different one first.

The architecture

Detection and redaction run as JavaScript inside the page you are viewing. Your text is read from a textarea, matched against the rules, and rendered back into the output pane. It never enters a network request because there is no endpoint that accepts it.

This is not a policy commitment that could be revised. It is a property of how the thing is built. A server cannot leak text it was never sent, and a retention policy is irrelevant when there is nothing to retain.

Verifying it yourself in thirty seconds

Do not take our word for it. The claim is checkable with tools already in your browser:

1. Open your browser's developer tools (F12, or Cmd+Option+I on a Mac).
2. Switch to the Network tab.
3. Clear the existing entries.
4. Paste text into the tool and watch it get scanned.

Nothing appears. No request carries your text, because no request is made at all while you type.

Try the same check on any tool that claims client-side processing. It is the fastest way to tell a claim from a fact, and it takes less time than reading the privacy policy.

The second-order consequence

This constraint shapes decisions that would otherwise be easy.

The site loads no external fonts, no analytics script from a CDN, no third-party widgets. Not because those are dangerous in themselves, but because the moment the page makes requests to other hosts, "the Network tab stays silent" stops being a check you can run in thirty seconds. Any request muddies the signal, so there are none.

The rules are hard-coded in a file served with the page rather than fetched from a server, for the same reason. Fetching them would be a network request. It would also mean the detection logic could change under you between visits, which is exactly the kind of opacity the tool exists to avoid.

What you give up

Honesty requires stating the cost. Client-side means:

• No rule updates without a deploy. A new vendor key format requires a code change and a release, rather than a database row.
• No server-side intelligence. No machine-learning model deciding whether a sentence is confidential, because that would require sending the sentence somewhere.
• Rules visible to everyone. Including, in principle, someone who wanted to craft text that evades them.

The last one is worth a moment. Auditable rules are a feature, not a vulnerability, because the threat model here is accidental disclosure by you, not evasion by an adversary. Nobody is trying to sneak secrets past your own redaction tool. Keeping the rules secret would buy nothing and cost you the ability to check what the tool actually does.

The general principle

When a tool asks for sensitive data, the useful question is not "do I trust this company" but "what would this company have to do to betray me, and could they even if they wanted to".

Architecture answers that question more reliably than a promise does.