Skip to content
ZeroServer.tools

JSON Anonymizer & PII Redactor

Detect and redact personal data inside a JSON structure — emails, phone numbers, SSNs, credit cards, IPs, names and more.

Preset Sample Payloads
Fields to Redact
Validation
Valid JSON
Input Size
428 B (17 lines)
Output Size
730 B (17 lines)
Processing Time
0.1 ms
11 PII values redacted:Names × 1Emails × 2Phone numbers × 2SSNs × 1Credit cards × 1IP addresses × 1Dates of birth × 1Addresses × 2
Drop a .json file

How JSON PII redaction works

This tool walks every key and value in your JSON document and flags likely personal data using two detection passes: a key-name pass that matches field names like email, ssn, or creditCard against common naming conventions, and a value-shape pass that scans free-text strings for embedded patterns — email addresses, phone numbers, US Social Security numbers, IPv4 addresses, and credit card numbers (verified with a Luhn checksum to avoid false positives on plain digit strings). Matches can be handled three ways: masked with block characters while preserving the first character and rough length, replaced with a realistic-looking placeholder value, or one-way hashed with SHA-256 so the same input always redacts to the same token (useful for keeping referential integrity across a dataset while removing the real value), or the key can be removed from the object entirely. Everything runs locally in your browser — the JSON you paste is never uploaded anywhere, which matters since the whole point of the tool is handling sensitive data safely.

Built and maintained by Meet Shah · Last updated

What this tool is used for

  • Redacting personal fields from a payload before sharing it.
  • Hashing an identifier so records can still be correlated without exposing it.
  • Producing a sanitised fixture from real data.
  • Checking which fields in a payload hold personal data.
  • Preparing a sample for a vendor or a ticket.

Frequently Asked Questions

Is replacing names enough to anonymise data?
Rarely. Combinations of quasi-identifiers — postcode, birth date, job title — re-identify people even with names removed, which is what k-anonymity research showed repeatedly. Removing direct identifiers is the first step, not the whole job.
Should the replacement be consistent for the same value?
It depends. Consistent pseudonyms preserve relationships so the data stays useful for testing joins; random ones per occurrence are safer but destroy referential integrity. Choose from what the data is for.
What is the difference between masking and redaction?
Masking keeps the shape — a card number becomes `**** **** **** 1234` — while redaction removes the value entirely. Masking preserves format validation; it also leaks the part you left visible.
Does anonymised data fall outside privacy law?
Only if it is genuinely irreversible. Pseudonymised data — where a key could restore identities — remains personal data under GDPR, which is a distinction that catches teams out.
Does the data leave my browser?
No. Processing happens locally, which matters more here than for most tools — the input is by definition the sensitive version of the document.

Common errors and gotchas

  • Assuming detection catches everything, when custom identifiers and free-text fields defeat patterns.
  • Hashing without a salt, which leaves values recoverable by a dictionary of likely inputs.
  • Redacting a field and leaving another that derives from it.
  • Treating masking as anonymisation, since context often re-identifies a person.
  • Redacting a value but leaving it intact inside a nested duplicate of the same object.

Related Developer Utilities tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate