The practical guide to reading, formatting and debugging JSON

The entire grammar is objects, arrays, strings, numbers, true, false and null. That is the whole specification (RFC 8259). Everything that feels like JSON but is not — comments, trailing commas, single quotes, unquoted keys, NaN, Infinity, undefined, functions, dates as objects — comes from JavaScript object literals or from formats like JSON5 and HJSON. Strict parsers reject all of it.

This matters because most confusion comes from a mental model borrowed from JavaScript. If you can write it in a .js file it does not follow that a JSON parser will accept it.

Across code reviews and support threads the same handful of mistakes account for nearly every invalid document:

• Trailing comma after the last property or array element — valid in modern JS, invalid in JSON.
• Single-quoted strings or unquoted keys copied out of source code rather than out of a response.
• Comments left in a config file, usually // or /* */ from a hand-edited template.
• Unescaped control characters — a real newline or tab inside a string literal instead of \n or \t.
• Concatenated documents: two JSON objects streamed back to back, which parses the first and then fails on 'unexpected non-whitespace character after JSON'.
• Truncation: a response cut short by a timeout, producing 'unexpected end of JSON input' at the very last position.

Browser parsers report a position, and that position is nearly always the character where the parser gave up — not necessarily where the mistake is. A trailing comma on line 40 is reported at the closing brace on line 41, because the comma only becomes illegal once the parser sees what follows it. So read the reported location, then look at the token immediately before it.

Line and column are more useful than a raw character offset, which is why the validator on this site converts the offset for you and shows the surrounding context. Once you know the line, formatting the document first makes the fix obvious: minified JSON on a single line makes every error 'line 1'.

When a response is several megabytes, do not scroll it. Work top-down instead: format it, then collapse everything and expand only the branch you care about — a tree viewer turns a 20,000-line dump into a shape you can navigate in seconds.

• Format first so error locations become meaningful.
• Validate to get a clean verdict before you start reasoning about the data.
• Use a viewer to explore structure and confirm which fields are actually present.
• Convert to CSV when you need to eyeball a list of records or hand it to a non-developer.
• Minify only at the end, when you are shipping the payload somewhere size-sensitive.

A document can be perfectly valid and still lose data. JSON numbers have no defined precision limit, but JavaScript parses them into IEEE-754 doubles, so any integer beyond 9,007,199,254,740,991 silently loses accuracy. Snowflake IDs, Twitter-style identifiers and financial values in minor units are the usual victims — the fix is to transmit them as strings.

Unicode is the other quiet trap. JSON is UTF-8 by default and emoji or CJK characters are perfectly legal, but a byte-order mark at the start of a file makes the very first character invalid, and a file saved as Latin-1 will produce mojibake rather than a parse error. If a document looks valid but renders wrongly, check the encoding before you doubt the parser.

Store configuration in a format designed for humans if you need comments — YAML, TOML, or JSON with a documented schema — and reserve JSON for machine interchange. Validate at boundaries rather than deep inside your code, so a malformed payload fails at the edge with a clear message. And when you are debugging someone else's API, format and inspect the raw body before you write a single line of parsing code; most 'the API is broken' tickets turn out to be a wrapper field nobody expected.