Redact Sensitive Data

Features

• ⚠️ The first line states that regex redaction is never complete, and lists what it cannot see
• Eight kinds masked: phone numbers, ID numbers, card numbers, emails, API keys, JWTs, private key blocks and IP addresses
• Five presets: everything, contact, identity and cards, secrets, and network
• ⚠️ ID numbers require a correct check digit and card numbers must pass Luhn — a false positive is worse than a miss
• ⚠️ Keys are only recognised with an explicit prefix (`sk_live_`, `AKIA`, `ghp_`, `AIza` and friends): a generic rule would also destroy hashes and Base64 payloads, which is changing the user’s data
• Emails keep their domain (`zh····@example.com`) so you can still see which provider it is
• Private key blocks are replaced with `[PRIVATE KEY REDACTED]` — masking them into stars would look like a half-leak
• The mask character is configurable — a different character suits some contexts better
• An optional “list only” mode showing each before-and-after pair, so you can check before deciding to send
• ⚠️ No span is rewritten by two rules — occupied ranges are tracked

How to use

1. Paste the text
2. Choose which kinds to mask (everything by default) and change the mask character if you like
3. The result gives the redacted text and a count of what changed
4. Unsure? Switch to “list only” and see exactly what would change first

FAQ

Is it safe to send once it is redacted?

No. Regex only recognises fixed shapes, and “sensitive” is not about shape: a person’s name, address, employer, diagnosis or itinerary sitting in the prose is completely invisible to it. Nor does it know your own numbering schemes (`UID-9f3a2b`). So the role here is a safety net before sending — it catches the most common leaks, but whether to send is still your call.

Why is an ID number with a bad check digit left alone?

Because redaction changes the content, and a false positive is worse than a miss: a miss is invisible to the user, while a false positive is right there in the output and makes them think the tool broke their data. So only certain matches are touched — ID numbers need a correct check digit, card numbers must pass Luhn. The cost is that a “right shape, wrong check digit” ID is not processed; such a string is usually not an ID to begin with.

Why were some keys not recognised?

Because only keys with an explicit prefix are recognised (`sk_live_`, `AKIA`, `ghp_`, `xoxb_`, `AIza` and so on). A generic rule — “a long run of letters and digits” — would also destroy hashes, Base64 payloads and meaningless IDs, which is editing the user’s data rather than redacting it, and leaves them with something unusable. For a custom key without a prefix, mask it by hand.

Why does an email keep its domain?

Because the domain is often the very thing being looked at: `zhangsan@company.com` and `zhangsan@gmail.com` differ a great deal when you are debugging, and “this is a work address” is rarely sensitive in a ticket. So the local part is masked and the domain kept. If even the domain must go, change the mask character and run it again by hand.