How to Safely Format JSON Without Leaking API Keys

October 30, 2026 · 6 min read

To format JSON without leaking API keys, use a formatter that processes the text entirely in your browser, scan the payload for secrets before you do anything else with it, and redact tokens before you copy, save or share the result. Never use a tool's "save", "share" or "recent" feature on real payloads unless you know exactly where that data is stored and who can read it.

That sounds obvious, but formatting is the moment people are least careful. You are debugging, a 4,000-character response is unreadable on one line, and the fastest fix is to paste it into the first result for "json formatter". This guide explains where that paste can end up and gives you a routine that takes seconds.

Where JSON leaks when you format it

The formatting itself is harmless: indenting text does not expose anything. The risk comes from what happens to the text around the formatting step.

Check whether a formatter is really client-side

"We do not store your data" is a claim. You can check the behavior yourself in under a minute with your browser's developer tools:

1. Open the formatter, then open DevTools (F12 or Cmd+Option+I) and switch to the Network tab.
2. Clear the list, paste a harmless sample such as {"test": "canary-123"} and click Format.
3. Look for new requests. Use the filter box to search for canary-123. If any request body contains it, the text left your machine.
4. For a stronger test, set the Network throttling dropdown to Offline and format again. A client-side tool keeps working.

Our JSON formatter is built to pass this test: parsing, formatting, validation and secret detection run in your browser, and the security page explains how to verify it.

What counts as a secret in JSON

API keys are the obvious case, but payloads you format during debugging often carry more than that. Watch for:

• Cloud credentials: AWS access key IDs start with AKIA (long-term) or ASIA (temporary) and come with a secret access key.
• Provider tokens with recognizable prefixes, for example GitHub tokens (ghp_, github_pat_), Stripe secret keys (sk_live_) and Slack tokens (xoxb-, xoxp-).
• Bearer tokens and JWTs. A JWT is three base64url segments separated by dots and usually starts with eyJ. Its payload is only encoded, not encrypted, so anyone can read the claims.
• Database connection strings with an embedded password, such as postgres://user:password@host:5432/db.
• Private keys (-----BEGIN PRIVATE KEY-----), webhook signing secrets and session cookies.
• Personal data: emails, phone numbers, addresses and payment details in API responses.

A five-step routine for sensitive payloads

1. Format locally. Use a browser-only tool or a CLI (jq . response.json or python -m json.tool response.json). Neither sends data anywhere.
2. Scan before you share. Run the JSON secret scanner over the payload. It flags keys by known prefixes, suspicious field names like password or client_secret, and high-entropy strings.
3. Redact, do not delete. Replace values with a label such as "[REDACTED:aws_secret]" instead of removing keys, so whoever reads it still sees the structure.
4. Share the minimum. If a colleague needs one nested object, query just that part with the JSONPath tester instead of sending the whole response.
5. Rotate anything that slipped. If a live secret was pasted somewhere you do not control, treat it as exposed and rotate it. Deleting the message does not undo a copy.

Redact JSON from the command line

If the payload is already in a file, jq can redact known fields while keeping the document valid. This walks every object and replaces the value of any key that looks sensitive:

jq 'walk(if type == "object" then
  with_entries(
    if (.key | test("pass(word)?|secret|token|api[_-]?key|authorization"; "i"))
    then .value = "[REDACTED]"
    else . end)
  else . end)' response.json > response.redacted.json

walk is built into jq 1.6 and later. Key-name rules miss secrets stored under neutral names like value or data, so pair this with a pattern-based scan rather than relying on it alone.

Sharing a formatted payload safely

Sometimes you really do need to send a payload to someone. In order of preference:

• Send a redacted copy through a channel your team already trusts (your ticket system or a private repository), not a public paste site.
• If you use a share link, prefer one where the data lives in the URL fragment (the part after #). Browsers do not send the fragment to the server in HTTP requests, so the host never receives the payload. Anyone with the full link can still read it, so redact first.
• Add an expiry or delete the share once the issue is resolved.

This is not hypothetical. In November 2025 researchers reported that saved snippets on two popular formatter sites were publicly listable and contained live credentials. See what happened and what to do.

Make it a habit

The routine above is only useful if it is the default. Bookmark a client-side formatter, keep a redaction one-liner in your shell history, and add secret scanning to your CI so mistakes are caught before they reach a repository. For config files specifically, see how to detect secrets in config files.