What this tool does, and what it cannot do
It finds structured identifiers in text — email addresses, phone numbers, payment cards, IP addresses, IBANs, API keys, URLs carrying query parameters — and replaces them with placeholders before you send that text to a third-party API. It runs entirely in your browser, which for a redaction tool is not a feature but a precondition.
Being direct about the limits, because overstating them would be worse than useless: this is pattern matching. It cannot find a person's name in a sentence, an address written in prose, a date of birth in context, or a medical or financial detail described in words. It removes the obvious. Treat it as a first pass and never as a compliance control on its own.
Why it matters even when the provider promises not to train
Major providers state that API data is not used for training by default, and that is worth something. It is not the whole picture:
- Retention. Requests are typically retained for a period for abuse monitoring. Data you never sent cannot be retained.
- Jurisdiction. Inference may run outside your data residency region unless you have specifically arranged otherwise, often at a price premium.
- Logs downstream of you. Prompts end up in your own application logs, error trackers and traces, which are usually far less locked down than your database.
- Contracts you signed. A DPA with your customer may prohibit sending their personal data to a subprocessor you have not listed, regardless of what that subprocessor does with it.
Redact last, not first
The common mistake is redacting the user's message and considering the job done. In a real system the prompt is assembled from several sources, and the surprises are rarely in the part the user typed:
- Retrieved documents, which may be arbitrary customer records.
- Conversation history, carrying anything said in earlier turns.
- Tool results injected mid-loop by an agent.
- Templates and examples with real data left in from development.
Redact the assembled prompt immediately before it goes out. Compose it in the prompt builder, then run the finished thing through here.
Redacted text is usually cheaper too
A pleasant side effect. Random identifiers are exactly the strings tokenizers handle worst: an API key with no recognisable substrings fragments into dozens of tokens, and a UUID into a dozen. Replacing them with [API_KEY] collapses that to one or two.
On a payload heavy with identifiers, redaction can cut the token count noticeably — the before and after counts above show it. Measure the redacted version across every model in the token counter if the difference looks material at your volume.
Notes on the individual patterns
Phone numbers are the least precise pattern here, because phone formats overlap with ordinary numeric text. Expect occasional false positives on things like version strings or reference numbers, and check the output rather than trusting it blindly.
Payment cards match on digit-run length rather than a checksum, so long numeric identifiers may be caught. That is the safer direction for this particular error to fall in.
API keys match the common prefixed formats. A bare random string with no recognisable prefix will not be caught — if you rotate secrets through prompts, the fix is architectural rather than a regular expression.
What to do beyond this
If you handle regulated data, this tool is a convenience for developers, not an implementation of your obligations. Real answers there are named-entity recognition running in your own infrastructure, tokenisation of identifiers before they ever reach a prompt, a signed DPA with the provider, and a data residency arrangement.
What this is genuinely good for: the daily case where an engineer is about to paste a production log, a support ticket or a customer record into an API to debug something. That is where most accidental disclosure actually happens.