Secrets & PII Scrubber

Logs, HAR files, crash reports and config dumps routinely contain things that should never leave your machine: customer email addresses and phone numbers, card numbers, session tokens, database URLs with embedded passwords and cloud access keys. Once that text is pasted into a ticket, a public issue, a chat channel or an AI assistant it is copied, indexed and retained by systems you do not control, and a leaked access key can be abused within minutes. This scrubber removes those values locally, before the text goes anywhere.

Each detector combines a pattern with a validation step to keep false positives down. Card numbers must have 13–19 digits and pass the Luhn checksum, IBANs must pass the ISO 13616 mod-97 check, IPv6 candidates are parsed group by group, and AWS secret keys are only matched when they follow a secret-style key name, because a bare 40-character Base64 string is indistinguishable from a hash. Phone detection is deliberately conservative: it matches international + numbers and separated North American formats, not every long run of digits, so order IDs and timestamps survive. When two detectors overlap, the more specific one wins (a JWT inside an Authorization header is reported as a JWT).

Pick the masking mode that fits the reader. Full redaction is the safest for public posts. Partial masking keeps the last four digits or the email domain so support staff can still match a record. Consistent pseudonyms replace each distinct value with a stable placeholder (EMAIL_1, IP_2), so you can still follow one user or host through a log without knowing who they are. Short hashes do the same across separate files, but an unsalted hash of a low-entropy value such as a phone number can be reversed by brute force, so treat it as pseudonymisation, not anonymisation.

Use it before attaching logs to bug reports, together with the log analyzer for spotting error spikes, or before sharing a HAR capture in the HAR viewer. To inspect a token you found rather than hide it, use the JWT decoder; to check whether a number is a real card or IBAN, use the credit card & IBAN validator; and for test fixtures that never contained real people in the first place, generate them with the mock data generator. Custom patterns can be tried out first in the regex tester.