JSON Formatter

JSON is a strict subset of what JavaScript object literals allow, and the gap between the two is exactly where most "invalid JSON" errors come from. A trailing comma after the last item in an array or object is legal in modern JavaScript but a syntax error in JSON. Single-quoted strings work fine in JavaScript and are rejected outright by JSON, which requires double quotes. Unquoted object keys — writing `{name: "value"}` instead of `{"name": "value"}` — are valid JavaScript shorthand and invalid JSON. None of these are obscure edge cases; they are exactly the habits picked up from writing JavaScript that quietly produce a document that looks like JSON but is not.

Comments are the other frequent source of confusion, because plenty of config file formats that look like JSON — and even some JSON-derived formats used deliberately — allow `//` or `/* */` comments, while the JSON specification itself has no comment syntax at all. Copying a "JSON" config file that actually contains comments into a strict parser fails immediately, and the fix is either removing the comments or recognising the file was never using standard JSON in the first place.

A parser that only reports "invalid JSON" without saying where leaves you scanning the entire document by eye for a single missing comma or unescaped quote, which becomes genuinely tedious past a few dozen lines. Reporting the exact line and column of the first problem turns that search into a direct lookup — the error is describing a specific character, not a vague overall failure — which is the difference between fixing a large API response in seconds versus minutes of manual scanning.

It is worth noting the error always points at the *first* problem the parser encounters, not necessarily every problem in the document: a document with two syntax errors will report the first one, and fixing it may reveal the second only on the next attempt, since a parser that has already failed to make sense of the structure cannot reliably keep looking for further issues beyond the first point it got confused.

Pretty-printed JSON, with consistent indentation and line breaks, exists for the human reading it — debugging an API response, reviewing a config file, understanding a data structure at a glance. None of that structure matters to a program parsing the same JSON, which is why minified output strips every character that exists purely for human readability: indentation, line breaks, and any whitespace between tokens that is not required to separate them. The data represented is identical in both forms; only the number of bytes needed to transmit or store it differs, often substantially for deeply nested structures.

The practical rule is straightforward: format JSON while working with it — reading, debugging, editing by hand — and minify it before it goes anywhere that pays for its size, such as an HTTP request body, a URL query parameter, or a value stored in an environment variable with a length limit.