Search DevTools

Jump to any tool or page

PII Redactor / Data Anonymiser

Redact emails, phone numbers, credit cards, IPs, government IDs, API keys, and names from a JSON or CSV payload. Everything runs locally in your browser — nothing is uploaded anywhere.

Settings

Input format
Detected as JSON when set to Auto.
Detectors
Custom fields to always redact
Session salt

Fake and Hash replacements are derived from this salt, so the same value always maps to the same replacement across the whole document. Regenerating it breaks that mapping.

generating…

Input is capped at 2,000,000 characters to keep redaction responsive in the browser.

Input

JSON or CSV

Output

Paste a JSON or CSV payload to see the redacted output here.

Send toJSON Formatter

Everything above runs entirely in your browser. This payload is never sent to a server — that is the entire point of a redaction tool.

Data Transformation

About PII Redactor

Paste text and have emails, phone numbers, card numbers, IP addresses, and similar identifiers detected and masked before the text goes into a log, a ticket, or a model prompt. Pattern-based redaction has a hard ceiling: a regex can recognise the shape of an identifier but not its meaning, so it will always catch structured data more reliably than a name buried in prose.

Related Data Transformation tools

JSON FormatterImage to JSONSheet to JSONJSON to CSV/XLSXHTML to PDF

Frequently asked questions

Why do some names and addresses slip through redaction?
Email addresses, card numbers, and IPs have rigid grammars, so a pattern matches them with near-perfect recall. Personal names have none — "Baker" is a surname and a trade, "May" is a name and a month. Street addresses vary wildly by country and rarely follow one shape. Pattern matching therefore treats these as best-effort. Treat redacted output as a substantial risk reduction rather than a guarantee, and keep a human review step for anything leaving a regulated boundary.
Does redaction alone make data safe to share?
Not reliably. Removing direct identifiers leaves quasi-identifiers behind, and combinations of those re-identify people surprisingly often — postcode, date of birth, and sex together pin down a large fraction of any population. Free-text fields are especially leaky because context reconstructs identity: "the only Kubernetes contractor in the Leeds office" names someone precisely without a single matched pattern. For genuine anonymity you need generalisation or suppression of those combinations, not just masking.
How are card numbers validated, and what about false positives?
Digit-shape matching alone flags plenty of harmless strings — order references, tracking numbers, and sequential test data all look like cards. The Luhn checksum filters most of that out, since a valid card number's digits satisfy a mod-10 check that random sequences fail roughly nine times in ten. It does not eliminate false positives entirely, and it deliberately still matches well-known test numbers such as 4111111111111111, because those appear in real logs and are worth masking anyway.
Should I replace values with placeholders or hashes?
It depends on whether you need to correlate. A fixed placeholder such as [EMAIL] destroys all linkage, which is the safest default but makes debugging harder when you need to know two log lines concern the same user. A keyed hash preserves that linkage while hiding the value, but only if the key is secret — an unsalted hash of an email or phone number is trivially reversed by brute force, since the input space is small enough to enumerate exhaustively.
What breaks when I redact structured formats like JSON or logs?
Naive substitution corrupts syntax. Replacing a value inside a JSON string with a placeholder containing quotes or brackets produces unparseable output, and redacting a fixed-width log record changes column positions so downstream parsers misalign every field after it. If the input is structured, parse it first and redact at the value level rather than treating it as flat text. Otherwise you may find you have swapped a privacy problem for an ingestion failure.