JSON privacy & safety tips

JSON from real systems often contains more than you notice at first glance: access tokens in headers, customer emails in nested objects, internal hostnames in error messages. Pasting that JSON into a ticket, a chat thread or an online tool can leak it to people and services that shouldn't have it. This guide covers where sensitive data hides and habits that keep debugging safe.

Where secrets and personal data hide

• Authentication: Authorization headers, bearer tokens, API keys, session cookies, refresh tokens and signed URLs (look for X-Amz-Signature, sig= or token= in query strings).
• Personal data: names, emails, phone numbers, postal addresses, dates of birth, IP addresses and device identifiers.
• Payment data: card numbers, bank details and billing addresses. These are often subject to regulations such as PCI DSS.
• Infrastructure details: internal hostnames, database connection strings, stack traces with file paths, and environment variables.
• Encoded values: a JWT or a Base64 string can contain readable personal data. Decoding a JWT's middle segment often reveals the user's email and ID; see How Base64 encoding works.

Habits that prevent leaks

1. Share the smallest example that reproduces the problem. If a bug involves one field, share an object with that field rather than the whole export.
2. Redact before you share. Replace sensitive values with clearly fake placeholders, keeping the structure intact. See Redact / sanitize JSON for patterns.
3. Prefer synthetic test data. Use test@example.com and other values from reserved ranges (example.com, IP addresses in 192.0.2.0/24) instead of copies of production records.
4. Rotate anything that leaked. If a token or key was pasted somewhere public, revoke it and issue a new one. Deleting the message isn't enough, because it may already be indexed, logged or backed up.
5. Check logs and fixtures. Request and response logging is a common source of leaked tokens. Mask sensitive headers at the logging layer.

Choosing tools that keep data local

Many online JSON tools upload what you paste to a server for processing. Before pasting sensitive data into any website, check whether processing happens in your browser or on the server.

The JSON Formatter, XML Formatter, UUID Generator, Base64 tool and User Agent Parser on this site process data locally in your browser. The GraphQL Client is different: to make cross-origin requests possible, it forwards the requests you send through our server. Our privacy policy explains exactly what is and isn't sent.

Be careful with share links

Share links that encode the data in the URL, like the share feature in the JSON Formatter, are convenient because nothing is stored on a server. But anyone who has the link can read the data, and URLs end up in browser history, chat previews and server logs. Only share links for data you'd be comfortable posting in the same channel as plain text. See How to share JSON data.

Local storage on shared computers

Some tools, including this one, can save your work in the browser's local storage so it survives a page reload. That's convenient on your own machine, but on a shared or public computer anyone using the same browser profile can see it. Turn the option off and clear the editor when you're done.

A quick checklist before sharing JSON

• Removed or replaced tokens, keys, passwords and cookies
• Replaced real emails, names and addresses with fake ones
• Checked encoded fields (JWTs, Base64) for hidden data
• Removed internal hostnames and connection strings
• Trimmed the payload to what's needed to explain the problem
• Chose a channel appropriate for what's left