PII Redactor

Redact PII from logs and support tickets before you paste them anywhere

You have a log excerpt, a support ticket, or a JSON blob that reproduces a bug perfectly — and it is full of customer email addresses, card numbers and API keys. You need to hand it to a vendor, attach it to a ticket, or paste it into a chat, and you need the sensitive values gone first. This tool scans the text you paste, highlights every structured identifier it recognises, and gives you a masked copy you can hand over.

Everything happens in your browser. The detection engine is plain JavaScript regular expressions running on the page; there is no upload, no server round trip, and no storage. That matters more here than on almost any other tool — a redaction service that uploads your unredacted text to redact it has already leaked it. Paste in the sample log, open your browser’s network tab, and you will see no request go out.

What the tool actually detects

Detection is pattern based, not model based. There are thirteen built-in types, each with its own regular expression and a severity used only for colour-coding the highlights. This is the complete list — nothing else is detected:

Read that list as a boundary, not a starting point. There is no detector for passport numbers, driving licence numbers, national insurance or SIN numbers, IBANs, medical record numbers, or non-US government identifiers. If your text contains those, the tool will leave them untouched and tell you nothing is wrong.

The three masking styles, and when each one is right

• Label replaces the value with its type in brackets — [EMAIL], [US_SSN], [CREDIT_CARD], [AWS_ACCESS_KEY]. This is the default and usually the right one: the reader can still see that an email was there, which keeps the log readable, without seeing whose.
• Partial keeps a shape hint. Emails become j•••@•••.com — first character of the local part, the real top-level domain, everything else bulleted. Other values keep their first and last character. Use this when you need to tell two different customers apart across a long log without identifying either.
• Full replaces the value with a run of block characters. Use it when even the length of a value is something you would rather not publish.

Whichever style you choose applies to every redacted type at once; there is no per-type style override.

A worked example

Click Load sample and you get a synthetic application log. Here is what happens to a few of its lines, and why:

• user=jane.doe@acme.example → the address is detected as an email. In label mode it becomes [EMAIL]; in partial mode j•••@•••.example.
• charged card 4111 1111 1111 1111 → sixteen digits split by spaces. The digits are stripped and run through Luhn; that number passes, so it is redacted as a card. A sixteen-digit order ID that fails Luhn is left alone, which is exactly the behaviour you want in a log full of numeric IDs.
• SSN 123-45-6789 → matches the SSN pattern. It does not also register as a phone number, because the phone pattern needs a 3–3–4 digit grouping or a leading + country code.
• customer 90210 → a false positive. Five bare digits match the ZIP pattern, so a customer ID gets flagged as a US ZIP code. This is the cost of pattern matching and it is worth seeing on your first run.
• dob 1987-03-14 → matches the date-of-birth pattern. So does every other ISO date in the log that is not already inside a timestamp, which is why the ISO timestamps at the start of each line get flagged too. The date pattern has no idea which dates are birthdays.
• Bearer eyJhbGciOi… → three dot-separated base64url segments, detected as a JWT and replaced whole.
• AKIAIOSFODNN7EXAMPLE → an AWS access key ID, matched on the AKIA prefix plus sixteen characters.
• John Smith, 1600 Pennsylvania Ave NW → not detected. Names and street addresses have no reliable regex, so the deterministic engine leaves them exactly as they are.

Turning individual types off

Above the two panes you get one chip per detected type, showing how many instances were found. Click a chip and that type stops being redacted — it stays highlighted in the original pane, dimmed, but passes through to the output untouched. This is the fix for the ZIP-code false positive above, and it is also how you keep the fields you actually need. IP addresses are the common case: if you are debugging a routing problem, redacting every IPv4 address destroys the evidence. Turn the IPv4 chip off, leave the email and card chips on, and you get a log that is still useful and still safe to send.

Overlapping matches

Several patterns can match the same span of text — a card number is also a long digit run, and a JWT is also a chain of base64 words. Each type carries a specificity ranking, and when two matches overlap the more specific one wins; if two matches are equally specific, the longer span wins. That is why an AWS key is redacted as an AWS key rather than as a generic API secret, and why a PEM private key is replaced as a single block rather than line by line.

The optional AI sweep, and what it is not

Because names and addresses are the obvious gap, the page offers a second, optional pass: a small instruction-tuned language model that runs in your browser via WebGPU. It downloads once (a few hundred megabytes to a couple of gigabytes depending on the model you pick) and is cached by the browser afterwards, shared with the other local-AI tools on this site. It needs a browser with WebGPU — Chrome, Edge, or Safari 18+ — and hardware acceleration switched on.

Two things about that pass are important. First, it is genuinely local: the model weights come down to your machine and the inference runs on your GPU, so your text still never leaves the browser. Second, and more importantly, it does not redact anything. It is prompted to list candidate person names, physical addresses and organisation names, one per line, as suggestions for you to review. Nothing it finds is masked automatically, and it only sees the first 4,000 characters of your input. Treat its output as a checklist for your own eyes, then remove what it found by hand or by editing your source text.

Failure modes worth knowing before you trust the output

• Unusual formatting defeats the patterns. An SSN written 123 45 6789 with spaces is not matched. A card number split across a line break is not matched. A phone number written as a bare run of ten digits is not matched, by design — that restriction is what stops every ten-digit ID in your log from being swallowed as a phone number.
• Encoded and nested data is invisible. Base64-encoded payloads, URL-encoded query strings, gzipped blobs pasted as text — the identifiers inside them are not in a form the patterns can see. Decode first, redact second.
• Structure is not analysed. The tool does not know that a JSON field called "customer_name" holds a name, or that a column in a CSV is a patient identifier. It only looks at value shapes.
• Free-text prose leaks. “The account belongs to the Henderson family at the Riverside branch” contains no pattern-matchable identifier and passes through completely intact.
• Redaction is not reversible or verifiable. The output is a plain string with substitutions applied; there is no key, no tokenisation map, and no way to reconstruct the original from the redacted copy.

This is not a compliance control

It is worth stating plainly, because tools like this get pressed into duties they cannot carry. An automated pattern matcher is a helper for a human who is about to share something, not a de-identification control you can point at in a GDPR, HIPAA or PCI DSS conversation. Those frameworks care about a documented process, an assessment of re-identification risk, and evidence that the result was reviewed — none of which a regex engine provides. Formal HIPAA de-identification, for instance, has two defined routes (expert determination and the Safe Harbor identifier list), and “I ran it through a browser tool” is neither.

The honest workflow is: redact here, then read the output before you send it. The two-pane layout exists for exactly that — the left pane shows what was found so you can see whether the tool understood your data, and the right pane is what you are about to hand over. When the counts look implausibly low for the text you pasted, that is the signal to slow down, not to ship.

Getting the result out

The redacted pane has a copy button and a download button that saves a redacted.txt file. Both act on the current output, with the current mask style and the current set of enabled type chips, so change your toggles before you copy rather than after. Detection re-runs about a third of a second after you stop typing, so on a very large paste give it a beat before you copy.

If you are working with structured JSON rather than free text, and you want to strip sensitive values while keeping the document’s shape intact, a key-aware redactor is a better fit than a free-text scanner — the shape of the document tells you which fields are sensitive, which is information this tool deliberately does not use.