Text Anonymizer / Redaction Tool

Text Anonymizer / Redaction Tool

Paste sensitive text into this browser-based text anonymizer to detect supported PII and replace it with consistent placeholders, a fixed mask, or nothing at all. Your text stays in the browser and is not uploaded.

Runs entirely in your browser. Nothing is uploaded. Detection uses deterministic regular expressions and validation checks only. It does not detect names, physical addresses, organizations, or other free-text identity clues. Always review the result manually.

How to use

1. Paste a log, support ticket, email, or contract excerpt into Sensitive text.
2. Choose Typed placeholders, Fixed masking, or Delete, and switch individual detection categories on or off.
3. Review the live output and counts, then copy the redacted output. Expand and copy the local mapping when you need an original-value comparison.

What it detects

• Email addresses using a practical RFC 5322 addr-spec subset with dotted domains.
• Common phone presentations, including E.164 international forms beginning with +, spaces, parentheses, periods, and hyphens. Phone matching is heuristic and does not prove that a number is assigned or callable.
• Valid textual IPv4 addresses and unscoped IPv6 addresses.
• Credit-card candidates containing 13–19 digits after spaces and hyphens are removed, only when they pass Luhn validation.
• IBAN candidates with two country letters, two check digits, and an alphanumeric body within the detector’s length bounds, but only when they pass the mod-97 check. Both compact and space-grouped forms are supported.
• Absolute http://, https://, and ftp:// URLs.
• US SSN-shaped values in the form XXX-XX-XXXX.

Each category has its own switch and detection count. When a category is disabled, matching values in that category remain unchanged. URLs are selected before nested host IP matches, so an IP inside a detected URL is not counted separately.

Replacement modes and consistency

Typed placeholders create a per-category sequence such as [EMAIL_1], [PHONE_1], or [IBAN_1]. The same exact raw value receives the same token everywhere it appears, so repeated values remain readable in logs. This is consistency pseudonymization rather than simple one-off masking.

The expandable mapping lists each original value and its typed placeholder. It can be copied locally for comparison or restoration work. Treat the mapping as sensitive data.

Fixed masking replaces each selected match with ███. Delete removes each selected match. These modes do not preserve repeated-value relationships.

How validation works

Email matching

The detector uses a practical subset of the RFC 5322 address form. It requires a dotted domain and rejects local parts that begin or end with a dot or contain consecutive dots. This is not a promise to support every RFC 5322 form, such as quoted strings, comments, domain literals, obsolete forms, or full internationalized addresses.

Phone matching

The detector recognizes common grouped phone forms and international forms beginning with +. It removes non-digit presentation characters for a simple length check: a selected candidate must contain 7–15 digits. This is deterministic pattern matching, not a country-specific numbering-plan lookup.

IPv4 and IPv6

IPv4 candidates must contain exactly four decimal octets. Every octet must be from 0 through 255, and ambiguous leading-zero octets are not accepted except for the single digit 0.

IPv6 candidates use hexadecimal groups. The implementation allows at most one :: compression marker and requires the expanded address to total eight groups. It rejects malformed compression, non-hex characters, and groups longer than four hexadecimal digits. IPv4 dotted tails and zone identifiers are outside the documented scope.

The sample 192.0.2.1 is fictional documentation data from the RFC 5737 192.0.2.0/24 TEST-NET-1 range. The sample 2001:db8::1 is from the IPv6 documentation prefix.

Credit cards and the Luhn check

A card candidate must contain 13–19 ASCII digits after spaces and hyphens are removed. A number that fails the Luhn check remains unchanged, so length alone does not trigger redaction.

The implementation processes digits from right to left, doubles every second digit beginning immediately to the left of the check digit, subtracts 9 when a doubled value exceeds 9, and accepts only when:

sum(transformed digits) mod 10 = 0

Checksum validity does not prove that an account exists. 4111111111111111 is included as a test fixture, not a real account claim.

IBAN and mod-97

For validation, spaces are removed and letters are uppercased. The detector accepts the generic structure of two country letters, two check digits, and an alphanumeric body containing 11–30 characters. It supports compact IBANs and IBANs written in space-separated groups, while protecting word boundaries so a valid IBAN is not extracted from a longer alphanumeric token.

1. Moves the first four characters to the end.
2. Converts A through Z to 10 through 35.
3. Reads the resulting digits with streaming arithmetic: remainder = (remainder × 10 + digit) mod 97.
4. Accepts the candidate only when the final remainder is 1.

A valid checksum does not prove that an account exists or belongs to a person. The displayed German IBAN is a validation fixture.

Important limitation

This tool performs deterministic rule detection only. It does not detect names, street addresses, organizations, or other identity clues expressed in free text. It intentionally does not connect to a service or run an NLP model. Review the complete output manually before sharing it.

The tool runs entirely in your browser. Nothing is uploaded by the page. However, privacy also depends on your own browser, device, deployment, and network environment.

In GDPR terminology, pseudonymization and anonymization are different concepts. Typed placeholders are pseudonymization-style handling, not a guarantee of legal anonymization. This is not a legal anonymization. This is not a GDPR compliance guarantee. The output and mapping may still contain sensitive information.

FAQ

Does this text anonymizer upload my text?

No. Detection and replacement run locally in the browser, and the tool is designed to make no upload. For high-assurance use, verify your own browser, device, deployment, and network environment.

What does the tool detect?

It detects supported email addresses, common phone presentations, valid IPv4 and IPv6 text, Luhn-valid 13–19 digit card candidates, mod-97-valid IBAN candidates, absolute HTTP/HTTPS/FTP URLs, and US SSN-shaped values.

Why was my long number not redacted as a card?

Card candidates must contain 13–19 digits after spaces and hyphens are removed, and they must pass the Luhn check. Length alone deliberately does not trigger a match, which helps avoid false positives.

Does it detect names, street addresses, or company names?

No. It uses deterministic patterns and validation algorithms rather than NLP. Names, physical addresses, organizations, and other free-form identity clues are outside its scope.

Why does the same email get the same placeholder?

Typed-placeholder mode maps each exact raw value to one token per category. Repeated occurrences of the same email can therefore become [EMAIL_1] each time, preserving log readability. Fixed masking does not preserve this relationship.

Can the mapping restore the original text?

The local mapping provides a comparison and restoration aid while it is available, but it is sensitive data. It is not encrypted escrow or a cryptographic recovery system.

Is the result GDPR-compliant or legally anonymous?

No legal guarantee is made. Pseudonymization and anonymization are distinct concepts, and deterministic replacement cannot guarantee that a person is no longer identifiable. Review the output and apply your organization’s requirements.

Should I paste real customer data?

Follow your organization’s security, retention, and handling policies. Use fictional fixtures for testing when possible, and manually review the entire result before use.