A JSON formatting checklist before sharing API data
JSON is easy to copy and surprisingly easy to overshare. Before pasting an API response into a ticket, docs page or chat thread, it is worth taking a minute to format it, remove sensitive fields and verify that the remaining sample still demonstrates the issue.
Start with formatting, not editing
Pretty-print the JSON first. Indentation reveals the shape of the object: which fields are nested, which arrays are long, and which values are repeated. Editing minified JSON by hand is where accidental deletions and invalid commas happen.
After formatting, check whether the top-level value is an object or an array. This matters when another person tries to reproduce the problem in a parser, a database import or a test fixture.
Redact fields deliberately
Redaction is more than replacing obvious secrets. A safe example should remove or alter any value that can identify a person, account, organization, private infrastructure or paid service.
- Replace tokens, API keys, session IDs and authorization headers.
- Change emails, names, phone numbers, addresses and customer IDs.
- Remove internal hostnames, private URLs and database identifiers.
- Keep field names when they are needed to explain the schema, but replace values with realistic placeholders.
Keep enough structure to reproduce the issue
Over-redaction can make a bug report useless. If the issue depends on a nested array, keep two or three representative items. If it depends on a null value, leave a null value in the sample. If it depends on date formatting, keep the date format but change the actual date.
The goal is not to make the data meaningless. The goal is to make it safe while preserving the shape that triggered the bug.
Validate after every edit
After redacting, run the JSON through a validator again. The most common mistakes are trailing commas, missing quotes, unescaped line breaks and comments copied from JavaScript objects. Strict JSON does not allow comments or trailing commas.
If the sample is going into documentation, also minify it once and parse it again. This catches invisible characters and confirms that the example can be consumed by machines.
Add context next to the sample
A clean JSON sample is strongest when paired with a short note: what endpoint produced it, what field is surprising, what output was expected and what output was observed. This saves reviewers from guessing and makes the sample useful long after the original conversation.