When is JSON Validator useful?
A JSON validator answers one question: does this text parse? That question turns up when a config file refuses to load, when an API rejects a payload that looked fine, or when a build fails on a line that seems correct. The answer here comes from the parser the browser already ships, so what this page accepts is exactly what a page or a script in the same browser would accept: no comments, no trailing commas, no unquoted property names, and no single-quoted strings. The document is read inside the tab and nothing is posted to a server, which matters when the payload holds tokens, addresses, or customer records.
The report is written to be read rather than skimmed. A failure names the problem in plain words, gives the line and the column of the first character that broke the parse, and says what to change. The usual causes are a comma left after the last member, a name pasted without its quotes, two members with no comma between them, a comment carried over from JavaScript, and a document that is really two objects stacked on top of each other. A pass is not a green tick either: it names the top-level type, counts the keys or items, lists the key names, and reports the nesting depth and the number of scalar values, so a document that parsed but is not the shape you expected is visible straight away.
Three limits are worth knowing. Only syntax is checked, so a document that parses but is missing a required field still passes. A duplicate key raises no error, because JSON.parse keeps the last value and drops the earlier one. Numbers are read as doubles, so an integer beyond two to the fifty-third loses precision on the way in and a long identifier is safer kept as a string. Beyond that, the JSON Formatter on this site indents the same document once it parses, and the JSON to CSV and JSON to Excel tools turn an array of records into a table.