LLM responses have a habit of repeating back the personal data you fed them — names, emails, phone numbers — and that text then lands in logs, traces, and analytics that were never meant to store PII. This tool strips it out first. Paste the output, pick the categories to redact, and copy clean text with sensitive values replaced by placeholders. Nothing leaves your browser.
How it works
The anonymizer runs a set of regular-expression matchers over the text, one per entity type:
- Emails, URLs, and IPv4 addresses — structured patterns that match cleanly.
- Phone numbers — international and grouped formats, with a guard that ignores too-short sequences.
- Card numbers (13-16 digits) and US SSNs — common financial and identity formats.
- Names — capitalised multi-word sequences, the hardest and least precise category.
Matches are replaced with fixed placeholders ([EMAIL], [PHONE], [NAME], …) and you get a breakdown
of how many of each were redacted. Matching order is chosen so that structured patterns like emails are
handled before looser ones like phone numbers, avoiding partial mangling.
Where LLM output PII shows up downstream
This tool is most useful when you are operating an LLM-powered feature and need to prevent personal data from leaking into adjacent systems:
Logging pipelines — application logs that capture requests and responses for debugging routinely store full LLM output. A user’s name, email, or account number in the response goes straight into your log aggregator, often without any retention limit.
Prompt caches — some LLM providers and self-hosted setups cache prompts and responses to reduce costs. Cached outputs containing PII persist beyond the original request.
Analytics and tracing — products like observability platforms that record LLM calls capture the full conversation by default. If a user’s address appears in the model’s response, it ends up in your analytics database.
RAG retrieved chunks — retrieval-augmented generation pipelines often include document chunks in the prompt. When the model quotes from those chunks in its response, the quoted PII is included in the output that gets logged.
Redacting at the output boundary — before the text enters any of these sinks — reduces both your compliance surface and your breach exposure.
What it is and isn’t
This is one-way masking for the common case of keeping PII out of downstream systems. It is not format-preserving encryption or reversible tokenization — once redacted, the originals are gone. For regulated, high-stakes anonymization you should layer a dedicated PII detection service and human review on top; regex alone will always miss context-dependent identifiers.
Tips
- Redact at the boundary: clean text the moment it leaves the model and before it reaches any log, cache, or analytics sink.
- Turn off categories you don’t need — leaving “names” on can over-match ordinary capitalised phrases.
- Pair it with the Prompt Injection Detector to both sanitise inputs and clean outputs around your LLM.
- Review the “redacted” count before copying — an unusually low count may mean the entity type was missed rather than absent.