JSON Parser & Formatter

Unexpected token is almost always a trailing comma. JSON does not allow the comma after the last element of an object or array, even though JavaScript, Python, and most linters accept it. It is the single most common reason a hand-edited config file stops parsing.

Unexpected end of input means a bracket or brace was never closed. The reported position is where the parser gave up, not where the mistake is, which is why formatting the document first is usually faster than reading the error: the indentation makes the unclosed level obvious.

Single quotes are not valid JSON. Neither are unquoted keys, comments, NaN, Infinity, or undefined. All of these are legal in a JavaScript object literal, and the difference between the two formats is what trips people up most often when copying a snippet out of code and into a config file.

Format when you are reading or debugging. Indentation is what makes structure visible, and a formatted document is the only practical way to find a missing bracket or understand an unfamiliar API response.

Minify when you are shipping. Removing whitespace from a large payload can cut its size meaningfully before compression, and for anything served over the network that is real latency. It makes no difference to files in your repository, where readability is worth far more than the bytes.

Keep formatted JSON in version control regardless. A minified file produces a single-line diff on every change, which makes code review useless and merge conflicts unresolvable.

Parsing runs entirely in your browser. API responses routinely contain access tokens, customer records, and internal identifiers, and pasting those into a site that uploads them to a server is a genuine data leak. Nothing here leaves the tab.

Because the work happens locally, file size is bounded by your machine rather than an upload limit. Very large documents are limited mainly by available memory, since the whole structure has to be held at once to be validated.