Censor JSON

Hide sensitive data in JSON by censoring strings, keys, and numbers using pattern matching.

Input (JSON)
Options
JSON Output
Output (Censored JSON)

Related Tools

Obfuscate JSON

Transform JSON data using Unicode escape sequences and randomization to make it harder to read.

Json

Hide JSON Strings

Mask all string values in JSON while preserving structure.

Json

Edit JSON

Edit JSON data with a feature-rich editor that supports syntax highlighting and formatting options.

Json

Analyze JSON

Display detailed information about JSON structure including type analysis, data type counts, and nested data exploration.

Json

What It Does

The JSON Censor tool lets you safely redact sensitive values from JSON data by replacing them with asterisks, custom placeholder text, or redaction labels like [REDACTED] or [MASKED]. Whether you're a developer preparing code samples for documentation, a DevOps engineer sanitizing application logs before sharing with a third-party support team, or a compliance officer ensuring personal data never leaves your system unmasked, this tool gives you precise control over what gets hidden and what stays visible. Simply specify the key names you want to censor — such as password, apiKey, ssn, or email — and the tool recursively traverses your entire JSON structure, finding and replacing matching values at every level of nesting. The original JSON structure, formatting, and non-sensitive values are preserved exactly as-is, so the output remains valid, readable JSON that accurately represents your data's shape without leaking its secrets. Unlike manual find-and-replace approaches that are error-prone and slow, this tool handles deeply nested objects and arrays automatically, ensuring no sensitive field slips through. It's an indispensable utility for anyone working with real-world JSON data who needs to share, debug, or document it safely.

How It Works

The Censor JSON applies its selected transformation logic to your input and produces output based on the options you choose.

It applies a fixed set of transformation rules to your input, so the output is stable and easy to verify.

All processing happens in your browser, so your input stays on your device during the transformation.

Common Use Cases

  • Redacting API keys, tokens, and passwords from JSON configuration files before posting them in public GitHub issues or Stack Overflow questions.
  • Sanitizing application log exports that contain user email addresses, IP addresses, or session tokens before forwarding them to an external support or monitoring vendor.
  • Preparing realistic but safe JSON payloads for API documentation, replacing live user data with masked placeholders while keeping the structure intact.
  • Achieving GDPR and HIPAA compliance by masking personally identifiable information (PII) such as names, dates of birth, and social security numbers in JSON data exports.
  • Creating anonymized data samples for unit tests or QA environments without having to manually craft fake data from scratch.
  • Stripping credentials from CI/CD pipeline artifacts or deployment manifests before archiving them in version control.
  • Sharing JSON bug reports or support tickets with vendors or colleagues without exposing your production database credentials or customer data.

How to Use

  1. Paste or type your raw JSON into the input field — this can be anything from a single object to a large nested structure containing arrays, objects, and mixed value types.
  2. Enter the key names you want to censor in the fields list, separating multiple keys with commas (for example: password, apiKey, email, ssn). Key matching is case-insensitive by default so 'Password' and 'PASSWORD' are both caught.
  3. Choose your preferred replacement text — common options include '********' for a visual redaction, '[REDACTED]' for a clear label, 'null' to nullify the value, or any custom string that fits your documentation style.
  4. Click the Censor button and review the output. The tool will recursively scan every level of the JSON, replacing all matching key values regardless of how deeply nested they are.
  5. Copy the sanitized JSON output using the Copy button and paste it wherever you need — in a bug report, documentation page, Slack message, or support ticket.

Features

  • Recursive deep-traversal censoring that finds and masks matching keys inside nested objects and arrays at any depth, so no sensitive value is accidentally left exposed.
  • Custom replacement text support — choose from common presets like asterisks or [REDACTED], or enter your own placeholder string to match your documentation standards.
  • Multi-key censoring in a single pass, allowing you to specify a comma-separated list of key names and redact all of them simultaneously without running the tool multiple times.
  • Case-insensitive key matching to catch variations like 'password', 'Password', and 'PASSWORD' across inconsistently formatted JSON payloads.
  • Structure-preserving output that maintains valid JSON formatting, correct data types for non-censored fields, and the original indentation style so the result is drop-in ready.
  • Array-aware traversal that processes objects nested inside arrays, ensuring that collections of user records or log entries are fully sanitized rather than partially masked.
  • Zero data retention — all processing happens in your browser, so your sensitive JSON never leaves your machine or gets sent to any server.

Examples

Below is a representative input and output so you can see the transformation clearly.

Input
{"email":"ada@example.com","token":"abc123"}
Output
{"email":"***","token":"***"}

Edge Cases

  • Very large inputs may take a few seconds to process in the browser. If performance slows, split the input into smaller batches.
  • Mixed formatting (tabs, line breaks, or inconsistent delimiters) can affect output. Normalize spacing first if needed.
  • Censor JSON follows the selected options strictly. If the output looks unexpected, re-check option settings and input format.

Troubleshooting

  • Output looks unchanged: confirm the input contains the pattern this tool modifies and that the correct options are selected.
  • Output differs from a previous run: confirm that the input and every option match, because deterministic tools should repeat when the settings are identical.
  • Unexpected characters: check for hidden whitespace or encoding issues in the input and try normalizing first.
  • Slow processing: reduce input size or try a modern browser with more available memory.

Tips

When censoring JSON for public documentation, prefer a consistent placeholder like [REDACTED] over asterisks — it signals intent clearly and looks professional in technical writing. If you're sanitizing logs for a vendor, double-check that all variations of a sensitive key name are covered (e.g., both 'auth_token' and 'authToken') since different parts of a system may use different naming conventions. For recurring sanitization workflows, keep a saved list of your standard censor keys so you can paste them in quickly each time. Always validate the output JSON in a viewer or linter before sharing to confirm the structure wasn't altered unexpectedly.

Data redaction is one of the most practical and frequently overlooked tasks in software development. Every day, developers copy a JSON snippet into a Slack message, paste a config file into a GitHub issue, or email a log export to a vendor — and in doing so, accidentally leak an API key, a database password, or a customer's personal details. The consequences range from a minor security incident requiring a credential rotation all the way to a serious compliance violation under regulations like GDPR, HIPAA, or CCPA. JSON is the lingua franca of modern web APIs, configuration management, and data interchange. It's expressive and human-readable, which makes it incredibly useful for debugging and documentation — but that same readability means sensitive values are immediately visible to anyone who sees the file. Unlike binary formats or encrypted payloads, a JSON object hands its secrets to any reader without ceremony. Data masking, also called data redaction or data sanitization, is the practice of replacing sensitive values with non-sensitive substitutes while preserving the overall structure and format of the data. There are several approaches: static masking replaces values permanently in the output (which is what this tool does), dynamic masking intercepts data at query time and is common in database systems, and tokenization replaces values with reversible tokens that can be detokenized by authorized systems. For most documentation, debugging, and sharing use cases, static masking is exactly what you need — it's simple, transparent, and irreversible by design. When choosing a replacement value, context matters. In technical documentation, [REDACTED] or [MASKED] communicates intent clearly to readers. In automated testing pipelines, using a realistic-looking fake value (like a properly formatted but fake email address) can be more useful than a placeholder, since it lets the code path exercise validation logic. For log archives, null or an empty string keeps the structure parseable by log analysis tools without retaining the sensitive data. It's also worth understanding the difference between key-based censoring (what this tool does) and pattern-based censoring. Key-based censoring targets values by their field name — it's fast, predictable, and works well when you control the schema. Pattern-based censoring uses regular expressions to find values that look sensitive (credit card numbers, email addresses, UUIDs) regardless of what key they're stored under — it's more powerful but also more likely to produce false positives. For most JSON sanitization tasks, key-based censoring is the right starting point, and you can layer pattern-based rules on top if your schema is less predictable. One nuance worth noting: nested structures in JSON can be surprisingly deep in real-world applications. A user profile object might contain a nested address object, which contains a nested verification object, which contains a token field. A naive find-and-replace on the raw text string will work in simple cases, but it can break JSON validity if the value contains special characters or if you're not careful about string boundaries. A proper recursive traversal — which is how this tool works — guarantees that every matching key at every depth level is correctly handled without corrupting the surrounding structure. For teams that sanitize JSON frequently, establishing a standard set of key names to always censor (a 'redaction policy') saves time and reduces the risk of human error. Common candidates include: password, secret, token, apiKey, api_key, authorization, auth, ssn, creditCard, cvv, email, phone, and dob. Storing this list somewhere accessible and pasting it into tools like this one each time you sanitize data turns a risky manual process into a fast, reliable habit.

Frequently Asked Questions

What is JSON censoring and why is it important?

JSON censoring (also called JSON redaction or sanitization) is the process of replacing sensitive values in a JSON document with placeholders or masked text, while keeping the structure and non-sensitive data intact. It's important because JSON is widely used to share data in bug reports, documentation, logs, and API examples — all contexts where real credentials or personal data should never appear. Without proper censoring, a single carelessly shared config file can expose API keys, database passwords, or user PII to unintended audiences.

Does this tool send my JSON data to a server?

No. The JSON Censor tool processes everything locally in your browser using client-side JavaScript. Your JSON input never leaves your device and is never transmitted to or stored on any server. This makes it safe to use even with highly sensitive data, since there's no network request involved in the censoring process. You can even use it offline once the page is loaded.

Can this tool censor values inside nested objects and arrays?

Yes. The tool performs a deep recursive traversal of the entire JSON structure, so it will find and censor matching keys regardless of how deeply they're nested. This includes keys inside objects nested within arrays, arrays nested within objects, and multi-level nesting combinations. Every occurrence of a specified key name throughout the document will be replaced, not just top-level fields.

What replacement text should I use when censoring JSON?

The best replacement text depends on your use case. For public documentation and code examples, [REDACTED] or [MASKED] is a professional, self-explanatory choice that clearly signals intent to readers. For visual emphasis in informal contexts like Slack or GitHub issues, a string of asterisks like '********' is commonly understood. If you're preparing data for automated test pipelines, a realistic fake value (like a properly formatted placeholder email) may be more useful than an obvious placeholder, since it allows validation logic to run correctly.

How is JSON censoring different from JSON encryption?

Censoring and encryption serve different purposes. Censoring permanently replaces sensitive values with placeholders — the original data is gone from the output and cannot be recovered from it. This is ideal for sharing data where the actual values are never needed. Encryption transforms values into ciphertext that can be decrypted back to the original using the right key — useful when data needs to be transmitted securely and restored at the destination. For documentation, bug reports, and log sharing, censoring is the appropriate choice because the goal is to remove sensitive data entirely, not protect it in transit.

Can I censor multiple keys at once?

Yes. You can specify multiple key names at once by separating them with commas in the key input field. For example, entering 'password, apiKey, email, ssn' will censor all four fields in a single pass through your JSON. This is much more efficient than running the tool separately for each sensitive field, especially when working with complex JSON structures that contain many different types of sensitive data.