JSON Formatting and Validation Guide for Developers

JSON is the default data format of the web, and it is also unusually good at failing in unhelpful ways. A missing comma, a trailing comma or a smart quote pasted from a document will produce a parser error that points at a line several rows away from the real problem. Most of the time JSON debugging is not hard, it is just slow, and the fix is to make the structure visible.

The syntax errors that cause most failures

• Trailing commas. JavaScript tolerates them in object literals; JSON does not, and this is the single most common cause of a parse failure.
• Single quotes instead of double quotes. JSON requires double quotes around every key and every string value.
• Unquoted keys. A key must always be a string, even when it looks like an identifier.
• Smart quotes pasted from a word processor. They look identical on screen and are a completely different character.
• Comments. JSON has no comment syntax at all. If you need comments, use JSON5, JSONC or keep a separate schema document.
• NaN, Infinity and undefined. None of them are valid JSON values. Use null, or encode the condition separately.

Formatting is a debugging tool, not just cosmetics

Pretty-printing adds indentation so nesting becomes visible. That matters because a surprising share of bugs are structural rather than syntactic: a value placed one level too high, an array that should be an object, or two sibling keys that should have been merged. Once the structure is readable, those mistakes are obvious at a glance. Most formatters also report the exact character offset of a failure, which is far more useful than the generic "unexpected token" message.

Working with JSON from APIs

1. Paste the raw response first and confirm it parses. Do not debug client code against data that is already invalid.
2. Minify before sending if size matters. Whitespace can be a meaningful fraction of a large payload on mobile connections.
3. Convert to CSV when a non-developer needs the data, and remember that CSV has no concept of nesting: flatten deliberately rather than letting the converter guess.
4. Keep null and missing distinct. A field explicitly set to null means something different from a field that was not returned.
5. Validate against a schema in your test suite, not only in production logs.

Handling large files without freezing the tab

Files above roughly ten megabytes become awkward for any browser-based editor. Very long lines are the specific problem: rendering a single line with two million characters will lock the interface even when parsing is instant. If you regularly work with payloads that size, minify first to see whether the bulk is whitespace, then format only the section you are debugging rather than the whole document.