Why the error position matters
Browsers report JSON parse failures as a character offset: "Unexpected token } in JSON at position 1043". Nobody can count to 1,043. This tool converts the offset into a line, a column and the offending line itself, with a caret under the exact character.
The things JSON does not allow
Most parse failures are one of a short list, all of which are legal in JavaScript and not in JSON:
- Trailing commas.
{"a": 1,}is valid JavaScript and invalid JSON. - Single quotes. JSON strings and keys must use double quotes.
- Unquoted keys.
{name: 1}must be{"name": 1}. - Comments. JSON has no comment syntax at all.
NaN,Infinity,undefined— none of these exist in JSON. Usenull.
Formatting versus minifying
Formatting adds indentation and line breaks for reading. Minifying strips every byte of whitespace for transmission. They are the same data — parsing either produces an identical structure — so the choice is purely about whether a human or a network is the next consumer.
Note that formatting also normalises the document: key order is preserved but duplicate keys collapse to the last one, and numbers are re-serialised, so 1.0 comes back as 1.
Why it matters where JSON is formatted
JSON pasted into a formatter frequently contains API responses, tokens and customer data. This tool parses in your browser and sends the document nowhere — you can confirm in DevTools that no request carries it. Many online formatters send the document to a server to format it.