Gera Tools

Regex Redaction Tester

Write a redaction regex, test it against sample text, and see matched and missed spans

Test a PII redaction regex against sample text in your browser. Matched spans that would be redacted are highlighted in green, while PII-like patterns your regex misses (emails, Luhn-valid cards, phones, SSNs, IBANs, JWTs) are flagged in red so you can catch leaks before production. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Is my sample text sent anywhere?

No. Both your regex and the sample text are processed entirely in your browser. Nothing is uploaded, so you can paste realistic test data without sending it through an external service.

Redaction pipelines fail quietly: a regex that looks right in review can still leak a phone number with an unusual separator or an email in an attachment field. This tool lets you exercise your redaction regex against realistic text and immediately see both what it catches and, just as importantly, what it misses.

How it works

The tool does two passes over your sample text:

  1. Your regex is compiled with the global flag and run across the text. Every non-empty match is highlighted in green — these are the spans your pipeline would replace with a redaction marker.
  2. Built-in PII detectors run independently for emails, phone numbers, credit cards, IPv4 addresses, US Social Security numbers, IBANs, and JWTs. The credit-card detector additionally verifies each candidate with the Luhn checksum so random digit runs are not reported.

For each detected PII span, the tool checks whether it overlaps any of your regex matches. If it does not, the value is shown in the red leak list — a piece of sensitive-looking data your regex would have let through.

Example

Suppose your regex only matches emails. Paste text that contains both an email and a credit-card number. The email is highlighted green (redacted), but the Luhn-valid card number appears in the red leak list because your pattern never covered it. That is the exact gap that causes production incidents, surfaced before you ship.

What each built-in PII detector catches

The leak detector runs a fixed panel of pattern-matchers on your text, independent of your regex. Understanding what each one looks for helps you know when the “missed” classification is a true leak versus a false positive:

  • Email addresses — classic RFC-5321 local-part@domain structure; handles subdomains and most common TLDs
  • Phone numbers — catches common patterns including optional country codes, dashes, dots, and parenthesised area codes; deliberately broad to reduce false negatives
  • Credit card numbers — 13–16 digit sequences validated with the Luhn checksum; random digit strings that fail Luhn are not flagged (this avoids false positives on long order IDs)
  • IPv4 addresses — four dot-separated octets; does not validate range (0–255), so some invalid-format IPs may appear
  • US Social Security Numbers — NNN-NN-NNNN pattern with common separator variants
  • IBANs — two-letter country code followed by check digits and the account number; coverage for major IBAN-using countries
  • JWTs (JSON Web Tokens) — the characteristic three-part base64url string separated by dots; useful for catching accidentally logged auth tokens

Any PII-like span that your regex does not overlap is listed in the red leak section. The intent is to surface gaps, not to certify your text as PII-free — domains vary and these heuristics cannot know about internal identifiers your application uses.

Designing a complete redaction regex

Most redaction failures come from covering only one PII type and forgetting the rest. A production redaction regex for a general-purpose text pipeline often needs to cover at least:

  1. Email addresses
  2. Phone numbers (in all the format variants your users might enter)
  3. Credit card numbers (Luhn-valid sequences)
  4. IP addresses (if your logs or notes might contain them)
  5. National identifiers (SSN, NI number, TFN — whatever is relevant to your users)
  6. Bearer tokens and JWTs (especially in API request/response logs)
  7. Custom internal identifiers (user IDs, account numbers, order references)

The built-in detectors cover items 1–6. Item 7 is where you need your own domain knowledge: paste a representative sample of your internal data format, build a regex that covers it, and use this tool to confirm it does not miss the standard types while you work.

Notes and tips

  • The global flag is always applied so matching is exhaustive; add i, m, or s as your pattern needs.
  • An empty-match regex (for example a*) is guarded so it cannot loop forever — zero-width matches are skipped.
  • The detectors are heuristics tuned to reduce false positives. They will not know about your internal account IDs or custom tokens, so pair this with domain-specific tests.
  • Everything runs locally, so it is safe to test with real-shaped sample data.