How to Remove Sensitive Data From JSON Before Sharing an API Response

Quick answer: Before sharing JSON, replace secrets and personal data with realistic dummy values that keep the same keys and types, then verify that the example still reproduces the bug. Check nested objects and arrays, not just the top level, and remember that tokens also hide in headers and URLs. A valid JSON file is not automatically a safe JSON file.

A teammate asks you to paste the failing API response into a support ticket. You copy the JSON, format it, and send it over. Five minutes later you notice an access token, a real customer's email address, or a private address in the payload.

After removing secrets and personal data, inspect the sample in the JSON Viewer and use JSON Compare to review the redacted result.

Start with an example that should not be shared

Imagine this API response:

{
  "customer": {
    "id": 1042,
    "email": "maya@example.com",
    "phone": "+1-555-0100"
  },
  "access_token": "example-live-token",
  "order": { "id": 801, "status": "pending" }
}

The record might be harmless if every value is test data. But in a real production response, the token and identifiers may be sensitive. A screenshot or a formatting tool does not remove that risk.

Bearer tokens deserve special attention. A JWT looks opaque, but its payload is only base64url-encoded, so anyone who receives it can read the claims inside; the JWT decoding guide shows how little effort that takes. Treat a token as both a credential and a data leak.

Replace values without destroying the structure

A more useful support example might be:

{
  "customer": {
    "id": 1001,
    "email": "user@example.test",
    "phone": "+1-555-0100"
  },
  "access_token": "[REDACTED]",
  "order": { "id": 801, "status": "pending" }
}

Keep the keys and data types you need to reproduce the error. If your actual issue concerns date parsing, leave a fake date in the same format; don't delete the field entirely. If it's a permissions issue, create a synthetic role and ID combination that reproduces it.

Fields worth checking

The exact list depends on your system, but inspect access/refresh tokens, API keys, authorization headers, cookies, passwords, private keys, customer contact details, addresses, payment information, IP addresses, session IDs, webhook secrets, and any free-text fields where users could have entered personal information.

Also inspect nested objects and arrays. A top-level secret is easy to spot; a private value inside events[17].metadata is not. When a payload is deep, a JSONPath or JSON Pointer expression such as $..email lists every occurrence of a key regardless of depth, which is a quicker audit than scrolling.

A small JavaScript redaction example

If you need repeatable examples in tests or logs, start with a controlled allowlist of fields to retain or a carefully reviewed sanitizer. Here's a simple recursive pattern illustrating key-based redaction:

const sensitiveKeys = new Set([
  'password', 'access_token', 'refresh_token', 'api_key', 'email'
]);

function redact(value) {
  if (Array.isArray(value)) {
    return value.map(redact);
  }

  if (value && typeof value === 'object') {
    return Object.fromEntries(
      Object.entries(value).map(([key, item]) => [
        key,
        sensitiveKeys.has(key.toLowerCase()) ? '[REDACTED]' : redact(item)
      ])
    );
  }

  return value;
}

const example = {
  customer: { email: 'maya@example.com' },
  access_token: 'secret-value',
  order: { status: 'pending' }
};

console.log(JSON.stringify(redact(example), null, 2));

Important: this is an illustration, not a security guarantee. It misses unrecognized key names, secrets embedded inside normal strings, binary attachments, URLs containing tokens, and many other patterns. For public data sharing, manual review or a tested policy-specific sanitization process is still essential. An allowlist of approved output fields is often safer than a denylist of suspicious names.

The same thinking applies before data reaches a log line, not just a ticket. If your services emit structured JSON logs, the redaction step belongs in the logger so that secrets never land in storage you later have to clean.

Validate after redaction

When you edit raw JSON by hand, you can accidentally remove a comma or quote. After sanitizing, use a JSON validator to check syntax and formatting. If you use an online tool for this step, prefer one that processes the document locally; JSON Prettifier runs entirely in the browser and does not upload the payload. Then review the final rendered output for sensitive information before you put it in a public issue, documentation page or community post.

A useful last check is to diff the redacted file against the original. Every difference should be a replaced value; if a key has disappeared or a type has changed, the example may no longer reproduce the bug.

Formatting and redaction solve different problems. Formatting makes JSON easier to read. Redaction makes a sample safer to distribute. Neither substitutes for authorization, encryption, secure logging or a privacy review.

For broader context, see the JSON security best practices and JSON in REST APIs articles.

A good debugging example gives another developer everything needed to understand the bug—and nothing they should not have received.