Anonymize JSON to Create GDPR-Compliant Test Data

Mask keeps shape and format so the UI still renders a plausible row. Note email and name use special mask rules; everything else uses first-2 + last-2.

Input:
{ "id": 91, "name": "Jonathan", "email": "jonathan@acme.com", "city": "Berlin" }

Strategy: mask · Deep: on

Output:
{ "id": 91, "name": "Jo****an", "email": "jo***@acme.com", "city": "Berlin" }

("city" untouched — "city" is not in the default PII terms.)

Two records reference the same email. With hash, both map to the same token — so a test that joins users to orders by email still joins.

Input:
[ { "role": "user",  "email": "sam@acme.com" },
  { "role": "order", "email": "sam@acme.com" } ]

Strategy: hash

Output:
[ { "role": "user",  "email": "b3f1c9aa" },
  { "role": "order", "email": "b3f1c9aa" } ]

fake increments a global counter, so the same source value gets different placeholders. Use hash, not fake, when referential integrity matters.

Input:
[ { "email": "sam@acme.com" },
  { "email": "sam@acme.com" } ]

Strategy: fake

Output:
[ { "email": "user1@example.com" },
  { "email": "user2@example.com" } ]   ← different tokens

remove drops the key. Add custom terms for fields the defaults miss. Removed keys are deleted, not blanked.

PII terms: email, name, nationalId
Strategy: remove

Input:
{ "name": "Lena", "nationalId": "DE-99887766", "plan": "pro" }

Output:
{ "plan": "pro" }

With Deep on, matched keys are anonymized at any depth, including inside arrays of objects.

Strategy: hash · Deep: on

Input:
{ "order": { "customer": { "email": "a@x.com" }, "items": [ { "sku": "X1" } ] } }

Output:
{ "order": { "customer": { "email": "7c2e10b4" }, "items": [ { "sku": "X1" } ] } }

Free tier allows files up to 2 MB. A larger export is blocked with an upgrade prompt. For GDPR test data you rarely need the whole set — export a 100-500 record sample under 2 MB, or upgrade to Pro (100 MB) for full datasets.

The input is parsed with JSON.parse after trimming. Trailing commas, single quotes, or a JS object literal throw a parse error and nothing is anonymized. Fix the syntax with json-format-fixer or json-prettifier first.

Detection is by KEY NAME only. An email buried in a notes or comment value is never matched, because notes is not a PII term and the tool never scans values. Replace or blank such fields manually, or strip them with json-key-filter.

Matching uses includes(): the term name also matches username, filename, and displayName; ip matches recipient and zip. This over-matching is intentional breadth but can mangle non-PII keys — use the narrowest terms that cover your real fields.

With strategy remove, the matched key is deleted and is NOT included in the 'fields anonymized' count (only retained, non-undefined results increment it). A low count after a remove run does not mean PII was missed — the keys are simply gone.

Values are coerced with String() before masking/hashing. A numeric phone: 4155550199 is masked as a string, and a boolean would be hashed as "true"/"false". The output value type changes to string for mask/hash/fake.

With Deep off, only keys on the top-level object (and array elements at the top) are evaluated; nested objects are copied verbatim, so PII inside them survives. Keep Deep on for typical GDPR exports.

If the comma-separated list is empty, the Anonymize button is disabled — there is nothing to match. Add at least one term.

mask preserves string length and the position of the @ in emails and the last 4 phone digits. For data shared externally, prefer hash or remove so attackers cannot infer the original from the shape.