Which key names trigger redaction?

A pattern match covering common sensitive-field names: password, secret, token, apiKey/api_key, accessKey, privateKey, auth, credential, ssn, creditCard, cardNumber, cvv, pin, email, and phone (case-insensitive, matching partial key names too, so userPassword still matches).

Does the match consider the value, or only the key name?

Only the key name. This tool doesn't inspect value content (like detecting an email pattern inside a string); it redacts based purely on what the field is called.

What happens to values under a redacted key that are objects or arrays?

The entire value is replaced with the string "[REDACTED]", regardless of its type, so a nested object under a key like credentials is collapsed into a single redacted marker rather than partially redacted.

How is this different from Hide JSON Strings?

Hide JSON Strings masks every string value regardless of its key, useful for a blanket redaction. This tool is targeted: it only redacts values under keys that look sensitive by name, leaving ordinary fields fully visible.

JSON Redactor Online - Redact Sensitive Fields

Overview

Introduction

Log payloads, debug dumps, and support tickets often carry a JSON object with a handful of genuinely sensitive fields, passwords, tokens, emails, mixed in with routine data. Manually redacting just those fields before sharing is easy to get wrong or forget entirely.

This tool automates that targeted redaction: it scans key names for common sensitive-data patterns and replaces only those values, leaving the rest of the document visible and useful.

What Is JSON Redactor?

A pattern-based redactor that checks every object key against a list of common sensitive-field name patterns (password, token, email, ssn, and others) and replaces matching values with the literal string "[REDACTED]".

Keys that don't match any pattern, and their values, are left completely unchanged, so the rest of the document stays useful for debugging or sharing.

How JSON Redactor Works

The tool recursively walks the parsed JSON document; at each key, it tests the key name against a case-insensitive regular expression covering common sensitive-field naming conventions.

If a key matches, its entire value (regardless of type) is replaced with "[REDACTED]" and the walk doesn't recurse further into it; if it doesn't match, the walk continues into that value normally.

When To Use JSON Redactor

Use it before pasting a JSON payload into a bug report, support ticket, or shared document, when you need most of the data visible but a few fields hidden.

It's also useful as a quick sanity check: run it over a log payload to see exactly which fields would be flagged as sensitive by name.

Often used alongside JSON String Masker, JSON Obfuscator and JSON Formatter & Beautifier.

Features

Advantages

Only redacts fields that look sensitive by name, keeping the rest of the document fully readable.
Covers a broad set of common sensitive-field naming patterns out of the box.
Runs entirely client-side, so the original unredacted data never leaves your browser.

Limitations

Detection is name-based only; a sensitive value stored under an unexpected key name (e.g. secretValue as x1) won't be caught.
This is a convenience tool for sharing debug data, not a substitute for proper secrets management or a compliance-grade PII scanner.

Examples

Redacting sensitive fields

Input

{"username":"ada.lovelace","password":"hunter2","email":"ada@example.com","apiKey":"sk_live_123"}

Output

{
  "username": "ada.lovelace",
  "password": "[REDACTED]",
  "email": "[REDACTED]",
  "apiKey": "[REDACTED]"
}

username doesn't match any sensitive pattern and stays visible; password, email, and apiKey all match and are redacted.

Best Practices & Notes

Best Practices

Always review the redacted output before sharing; automated pattern matching can miss unusually named sensitive fields.
Use Hide JSON Strings instead for a blanket redaction when you're unsure what might be sensitive.
Treat this as a convenience for sharing debug data, not a replacement for actually removing secrets from logs at the source.

Developer Notes

The sensitive-key pattern is a single case-insensitive regular expression tested against each key name independently (not a fixed list with exact-match lookup), which lets it catch variations like userPassword or api_key alongside the canonical password and apiKey spellings without maintaining an exhaustive enumeration.

JSON Redactor Use Cases

Sanitizing a debug payload before pasting it into a support ticket or bug report
Reviewing a log sample to see which fields would be automatically flagged as sensitive
Preparing a JSON example for documentation with credentials safely redacted

Common Mistakes

Assuming the pattern list catches every possible sensitive field name; unusual or company-specific naming can slip through.
Relying on this as a substitute for removing secrets from logging pipelines at the source.
Expecting value content (like an email address stored under a generically named key) to be detected; only key names are checked.

Tips

Rename obviously sensitive fields to a recognizable pattern (like ending in Token or Secret) upstream, so this tool catches them automatically.
Combine with a manual read-through of the redacted output before sharing anything externally.

JSON Redactor