Safely Sharing JSON: Redacting Sensitive Data
7 min read
Pasting a raw API response into a bug ticket, a chat message or a public gist is one of the easiest ways to leak a credential. Real payloads carry far more than the field you are debugging — access tokens, email addresses, internal IPs, sometimes raw passwords. This guide covers how to find that sensitive data and strip it out before you share.
What counts as sensitive
- Secrets: API keys, bearer tokens, JWTs, session cookies, signing keys.
- Personal data (PII): names, emails, phone numbers, addresses, government ids.
- Financial data: card numbers, account numbers.
- Infrastructure hints: internal hostnames and IP addresses that help an attacker map your network.
Why "I'll just delete the obvious bits" fails
Manual redaction misses things. Secrets hide under innocuous key names, a token can be embedded inside a URL, and a long base64 string is easy to overlook. And the moment you paste into a cloud tool to "clean it up", you have already sent the secret to that tool's servers — defeating the point. The scan itself must be local.
A safe redaction workflow
- Run the payload through a local scanner that flags common secret and PII patterns and suspicious key names.
- Review each finding — the path tells you where it is and the sample shows what matched.
- Redact: replace the value with a placeholder rather than deleting the key, so the structure stays intact and the JSON remains valid.
- Rotate any credential that was genuinely exposed — redacting a copy does not un-leak a key that already went somewhere.
The sensitive data detector does steps 1–3 in your browser: Detect lists every finding with its JSON path, and Redact returns a masked copy you can safely paste anywhere. Because it runs client-side, scanning for secrets never transmits them.
Redact, do not just hash
For debugging you usually want a placeholder like "REDACTED". If instead you need to prove two values were the same without revealing them, hash them with the hash generator — identical inputs produce identical digests, so you can correlate without exposing the value.
A note on JWTs
A JWT is only base64-encoded, not encrypted, so anyone who sees it can read its claims — and often use it. Treat a token in a payload as a live credential. You can inspect one safely with the JWT decoder, which also runs entirely in your browser; see understanding JWTs for the details.
Frequently asked questions
Is it safe to use an online tool to redact secrets?
Only if the tool processes data in your browser and uploads nothing. JSON Wallet's detector and redactor are fully client-side — see the Privacy Policy. A tool that sends your JSON to a server has already received the secret.
Can a detector catch everything?
No. Pattern matching catches common formats and suspicious key names, but custom or unusual secrets can slip through. Treat findings as prompts to review, and always eyeball the result before sharing.
If I redact a leaked key, am I safe?
Redacting your copy does not help if the key was already exposed elsewhere. Rotate any credential that genuinely leaked.
Related
See also understanding JWTs and, for the privacy model behind these tools, formatting and validating JSON.
Primary references
This guide is checked against the specifications and runtime documentation below. Examples are also run through JSON Wallet before publication.
Keep reading
What Is JSON? A Beginner’s Guide
JSON is the most widely used data format on the web. This guide explains what it is, how it is structured, and where you will run into it as a developer.
JSON Syntax Rules Explained (With Examples)
JSON has a small but strict grammar. This reference walks through every rule with valid and invalid examples so your data parses the first time.
Common JSON Errors and How to Fix Them
Every developer hits "Unexpected token in JSON" eventually. Here are the most common JSON errors, what causes them, and exactly how to fix each one.
Ready to put this into practice? Open the free JSON editor →