🕶️ Data Anonymizer

🎭 Mask mode

🔍 Detect

📝 Input text

📤 Anonymized text

📊 Detection counts

{{ countSummary }}
Total replacements: {{ totalReplacements }}

🧾 Replacements ({{ replacements.length }})

Each row reports the original PII value, the replacement, and the byte offset inside your input. Use this to audit the diff before publishing.

# Type Original Replacement Offset
{{ idx + 1 }} {{ row.type }} {{ row.original }} {{ row.replacement }} {{ row.offset }}
⚠️

ℹ️ About Data Anonymizer

What is data anonymization?

Data anonymization is the process of replacing personally identifiable information (PII) inside free-form text with safe substitutes. The goal is to keep the structure and surrounding context intact — for log review, demo screenshots, support tickets, training data, GDPR/CCPA disclosure, or analytics exports — while removing the actual identifiers. This tool detects seven common PII categories with regular expressions, validates the candidates that have well-defined checks (Luhn for credit cards, ISO 13616 mod-97 for IBANs, RFC 5952 shape for IPv6), and rewrites them in one of three masking styles.

The detection runs on a copy of the original text; the original is never sent anywhere. Replacements report their original value, replacement value, and offset so you can audit the diff before you publish the result.

Privacy: this runs in your browser

The interactive tool above runs entirely client-side. Your input text, the regex scanning, the Luhn and IBAN mod-97 checks, and the final masking all happen in your browser tab — no payload is sent to the server for the inline form.

A public API endpoint is also available at POST /api/tools/data/data-anonymizer for programmatic batch use. The API executes the same TypeScript logic module under Node.js on the server. Server access logs record the request size and timing for rate limiting, but the request body (your PII) is not persisted in application logs by design. If you need zero-trust treatment, prefer the interactive browser tool — that is what the default mount above does.

What gets detected

  • Email addresses — RFC 5322-style local-part with dot-separated host and a ≥ 2 character TLD. Example: [email protected].
  • Phone numbers — North American (NANP) and international E.164-ish formats: +1-555-123-4567, (555) 987-6543, +44 20 7946 0958.
  • US Social Security Numbers — strict NNN-NN-NNNN format, word-boundary anchored.
  • IBAN account numbers — ISO 13616 format (country + check + BBAN), 15–34 characters, validated with the mod-97 check. Invalid candidates are left untouched.
  • Credit card numbers — Visa / Mastercard / Amex / Discover digit runs validated by the Luhn algorithm. Numbers that fail Luhn are left as-is.
  • IPv4 and IPv6 addresses — IPv4 octets must be 0–255; IPv6 strings must parse under RFC 5952 (full, compressed, or mixed forms).
  • ISO 8601 dates — YYYY-MM-DD in years 1900–2999 with a valid month/day range. Off by default because dates are not always PII.

Mask modes

  • Token — every match is replaced with its category token, e.g. [EMAIL], [PHONE], [SSN], [IBAN], [CC], [IP], [DATE]. Best for stripping identifiers out of training data and logs.
  • Partial — keeps the leading character plus the last few identifying digits and obfuscates the middle. Example: [email protected] → f***@e***.com; 4111-1111-1111-1111 → XXXX-XXXX-XXXX-1111; 123-45-6789 → ***-**-6789; 192.168.1.42 → XX.XX.XX.42. Best for customer-facing redaction where the last few digits help users confirm "yes that's mine".
  • Counter — sequential identifiers per category: email-1, email-2, phone-1, etc. Best for preserving referential integrity across a document (the same email twice still becomes email-1) without leaking the value.

Use cases

  • Scrub log files before sharing with a vendor or pasting into a bug report.
  • Sanitize screenshots / chat logs for documentation, demos, or marketing copy.
  • Generate training data from production transcripts without exposing customers.
  • Anonymize support-ticket exports prior to a GDPR / CCPA subject-access disclosure.
  • Quickly check whether a string contains any PII at all (counts panel on the right).

Detection order and overlap handling

Longer / stricter patterns run before shorter ones so a credit card is not partially consumed by the phone regex. Order: credit cards → IBANs → emails → phones → SSNs → IPs → dates. Overlapping matches resolve in favour of the first-detected (highest priority) span; the runner-up is silently dropped. Replacements report their original text, replacement text, and offset in the input — useful for diffing.

Limitations

  • Regex detection cannot recognise novel identifier formats (custom employee IDs, internal account numbers). Add a pre-pass for those.
  • Names, mailing addresses, and free-form biographical text are not detected — they require an NLP model, not a regex.
  • Phone matching is intentionally generous; a 7-digit run that looks like a phone number will be flagged even if it isn't (false positives are safer than false negatives for PII).
  • Input is capped at 1,000,000 characters per request to keep the browser responsive.

References

API Usage Example:

POST /api/tools/data/data-anonymizer
Content-Type: application/json

{
    "text": "Contact [email protected] or +1-555-123-4567",
    "mask": "token",
    "enable": {
        "email": true,
        "phone": true,
        "ssn": true,
        "iban": true,
        "cc": true,
        "ip": true,
        "date": false
    }
}
Ready