JSON Formatter & Validator

JSON parse errors point at where the parser gave up, which is usually just after the real mistake. Four errors account for most of them. A trailing comma after the last item in an object or array is valid in JavaScript and invalid in JSON, so {"a": 1,} fails. Single quotes are not string delimiters in JSON; keys and string values both require double quotes. Unquoted keys are legal in JavaScript object literals and illegal in JSON. And unescaped control characters inside strings, most often a raw newline pasted from a text editor, break parsing mid-string.

If the error says something like "Unexpected token at position 428", format the document first. Once it is indented, the structure becomes visible and the offending line is usually within a few rows of where the nesting looks wrong.

Formatted and minified JSON are the same data, so the choice is purely about who reads it next. Pretty-print with two-space indentation for anything a human will open: config files committed to a repository, fixtures, documentation examples, and API responses you are debugging. Indentation makes a diff readable, which matters more than file size in version control, because a minified JSON file changes as one enormous line on every edit.

Minify for anything crossing a network or embedded in a page. Whitespace is typically 15 to 30 percent of a formatted JSON payload, and stripping it reduces transfer size before compression even starts. API responses, browser localStorage values, and JSON embedded in HTML data attributes should all be minified. One exception: gzip compresses repeated whitespace extremely well, so on a gzip-enabled endpoint the real-world saving is smaller than the raw byte count suggests.

Several everyday values have no native JSON type, and knowing the substitutes prevents data loss. There is no date type, so dates travel as strings, and the only format that is unambiguous across time zones and locales is ISO 8601 (2026-08-14T11:30:00Z). Sending 14/08/2026 guarantees an American consumer will read it as a different day.

There is no integer type distinct from float, and JSON numbers are parsed as IEEE 754 doubles in JavaScript, which loses precision above 2^53. Database IDs, Twitter-style snowflake IDs, and currency amounts in the smallest unit should be sent as strings if they can exceed that. There is also no comment syntax; anything a parser sees that looks like // outside a string is an error, so use a dedicated description field instead. Finally, JSON has no undefined and no NaN or Infinity, so those become null or fail to serialise.