About Sensitive Data Scanner
Every finding is a shape — a card number that passes the Luhn check, an IBAN that passes mod-97, a key with the prefix its provider uses — and each one is marked with how confident that shape is. What the scanner cannot do is know that a word is a person's name or a street; it says so on the page rather than implying a clean result means anonymous data. Findings can be labelled, masked, or replaced by stand-ins that keep the shape of what they replace — one stand-in per value, a mapping kept in the tab and nowhere else, and a Restore box that puts the real values back into whatever an assistant replied.
Before a log goes into a bug report, a CSV export goes to a contractor, or a config file gets pasted into a chat, somebody should read it for what it gives away. Nobody does, because a log is ten thousand lines. This scanner reads it for you, looking for sixteen shapes that personal and secret data take: email addresses, phone numbers, IPv4 and IPv6 addresses, GPS coordinates, card numbers, IBANs, US Social Security numbers, JSON Web Tokens, AWS, GitHub, Slack and Google keys, private-key blocks, credentials embedded in URLs, and passwords or tokens sitting on the right of an equals sign.
Shapes that can be checked are checked, which is what keeps the results useful. A run of sixteen digits is reported as a card only if it passes the Luhn checksum, so order numbers and timestamps do not light up; an IBAN must pass its mod-97 test; an IPv4 address must have four octets in range, so a three-part version number is left alone. Kinds that cannot be verified — phone numbers, coordinates, a four-part version number that is indistinguishable from an address — are marked medium confidence and listed second, because they will sometimes match other numbers.
The result is shown two ways. The highlighted view marks each finding in place, with a list beside it showing the kind and a partial mask — enough to recognise which customer or which key without reproducing it. The redacted view is a copy of the text with every finding replaced, either by a label such as [EMAIL] and [CARD] that keeps the text readable, by a mask that leaves the last four digits and the domain so a colleague can still tell entries apart, or by a stand-in — a made-up value of the same kind that can be swapped back afterwards. Copy the result, or download it as a file.
Stand-ins exist for the thing people now do daily: pasting a log, a ticket or an export into an assistant that belongs to someone else. A label destroys what the model needs, because [EMAIL] three times over could be three customers or one. A stand-in keeps that thread — each distinct value gets one stand-in, used everywhere it appears, however it was spelled — and keeps the shape, so an email still looks like an email and a card number still passes the Luhn check. The made-up values come from the ranges reserved for documentation: 192.0.2.x for addresses, example.com for mail, the 555-01xx telephone block, so no stand-in can be somebody's real server or mailbox. Paste the clean copy into the assistant, then paste its answer into the Restore box to read it with the real values back in place.
The mapping between real values and stand-ins sits in the tab and goes nowhere on its own — not into a share link, not into a saved copy. Copy it or save it as a JSON file if you will restore a reply in a later session, and keep it where you keep the original data, because the mapping is the key. That is also the reason this is pseudonymisation rather than anonymisation: while the mapping exists, most privacy law still treats the text as personal data. It lowers what you hand over; it does not put the text outside the rules.
It is honest about its limits because the limit matters. Detection is by form, not meaning: a person's name, a street address, a date of birth written in words, or a diagnosis have no shape a pattern can recognise, and no finding here says anything about them. A clean result means none of the sixteen shapes were present. It does not mean the text is anonymous, and the page says exactly that above the findings. Names, companies and project code names have to be typed into the box under the text; once listed they are matched literally, whatever their capitalisation, and replaced like any other finding.
Common use cases
- Cleaning a server log of customer emails and IP addresses before posting it to a public issue.
- Checking a CSV export from a CRM for card numbers or SSNs that should never have been in it.
- Catching a leaked API key or password in a config file before it is committed.
- Redacting a support transcript for a training deck.
- Auditing a data sample from a vendor for identifiers before agreeing to process it.
- Asking an AI assistant to diagnose a production log or draft a reply to a customer ticket, then restoring the real names and addresses in its answer.