JSON validator

A validator answers one question, will a parser accept this, and the useful part is where it stops. Engines report a character offset: "Unexpected token } in JSON at position 2841" is accurate and no help at all in a four-thousand-character body, so the offset is converted here into a line and a column you can go to.

The grammar is smaller than people expect and refuses things that look reasonable. Numbers take no leading plus, no leading zero and no bare decimal point, so 0123, +5, 1. and .5 are all rejected; NaN and Infinity cannot be written at all, which is why a serialiser that produced one has already gone wrong upstream. Strings must be double-quoted, and every character below U+0020 has to be escaped. A real tab or newline sitting inside the quotes is a syntax error, which is what breaks a payload assembled by pasting multi-line text into a field. And a byte order mark is not part of the grammar, so a file Excel or Notepad saved with one fails at the very first character.

One thing worth knowing before you trust a rejection from somewhere else: what counts as a whole document changed. Since RFC 7159 in 2014 any value stands alone, so "ok", 42 and null are each complete JSON. RFC 4627, from 2006, required an object or an array at the top, and an endpoint written against that older rule will refuse a document this page calls valid. Duplicate keys sit in a similar gap: the specification says names SHOULD be unique and leaves the rest undefined, so a document with two of the same key is not invalid and is read differently by different parsers.

What validity does not buy you is the shape. A missing required field, a number sent as a string, an ISO date where an integer was expected: all of them parse. That is schema validation, a separate job done with JSON Schema, and the distinction matters because "the JSON is valid" gets offered as a reason an integration should work when the real problem is a field the receiver needed and did not get.