Text Anonymizer & PII Scrubber
Redact emails, phone numbers, credit cards, and IP/MAC addresses from pasted text
Redaction rules
0 found
3c:22:fb:aa:bb:cc
0 found
2001:0db8:85a3::8a2e:0370:7334
0 found
192.168.1.1
0 found
4111 1111 1111 1111
0 found
+1 (555) 123-4567
0 found
0 total redactions applied
How the Text Anonymizer works
This tool scans pasted text for common personally identifiable information (PII) patterns — email addresses, phone numbers, credit card numbers, IPv4/IPv6 addresses, and MAC addresses — and replaces each match with a configurable placeholder mask like [EMAIL] or [PHONE]. Toggle any category off if you want to keep that type of data untouched, or customize the mask text per category (for example, swapping [CARD] for <redacted>).
Detection uses regular expressions tuned to reduce false positives: credit card candidates are verified with the Luhn checksum (the standard mod-10 algorithm real card numbers must satisfy) before being redacted, and phone numbers require a plausible digit count. Matching runs in a defined order — MAC, IPv6, credit card, IPv4, then phone — so a value can't be double-matched by an unrelated rule.
Everything happens instantly in your browser as you type. No text is ever uploaded or sent anywhere, which makes this safe to use on real logs, support tickets, or customer data before sharing them in a bug report, chat, or public forum.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Scrubbing a log extract before attaching it to a ticket or a bug report.
- Redacting personal data from a support transcript before sharing it.
- Preparing a sample of real text for a colleague without the identifiers.
- Checking which categories of personal data a body of text actually contains.
- Scrubbing a whole log file in one pass rather than word by word.
Frequently Asked Questions
- What does anonymising actually remove?
- Direct identifiers it can recognise — names, emails, phone numbers, addresses — replaced with placeholders. What it cannot remove is indirect identification, where a combination of non-identifying facts narrows to one person, which is the harder half of the problem.
- Is removing names enough for GDPR?
- No. GDPR distinguishes anonymisation, which is irreversible and takes the data out of scope, from pseudonymisation, which merely replaces identifiers and remains personal data. Text with names swapped for tokens is usually the second, not the first.
- What is the re-identification risk?
- Higher than it feels. Studies have repeatedly shown that a small number of quasi-identifiers — postcode, birth date, sex — uniquely identify most of a population. Free text is worse still, because a distinctive incident description identifies a person to anyone who was there.
- Should this be used for a formal disclosure?
- Not on its own. Legal and clinical redaction needs a documented process with human review, because the cost of one missed identifier is not proportional to the number caught. Automated extraction is a first pass that reduces the reviewer's workload.
- Does the text leave my machine?
- No — the processing runs in your browser and nothing is transmitted. That matters more here than for most tools, since the input is by definition the material you least want to send to a third-party service.
Common errors and gotchas
- Assuming pattern matching finds everything, when names, addresses and free text defeat it.
- Treating masking as anonymisation, since surrounding context often re-identifies a person.
- Using a consistent placeholder per value, which preserves the ability to link records.
- Overlooking identifiers in a format the patterns do not cover, such as an internal customer reference.
- Relying on the built-in categories when your data holds an identifier none of them match.