JSON validator

Anything can tell you that JSON is invalid; a browser console does it in one line. What is worth having is where, and every parser is bad at saying so in a way you can act on. "Unexpected token }" in a four-hundred-line file is a statement of the obvious with no address attached.

So this reports the line and the column, prints that line, and puts a caret under the character. In practice that is enough to see the problem without opening the file — a missing comma is visible the moment you can see the line above it, and the caret is almost always sitting on the token that came after the thing you forgot.

This is the single most useful thing to know about reading a JSON error. A parser is content until something cannot follow what came before, so a missing comma at the end of line 12 is reported at the start of line 13, where the next key appears and is not allowed to.

So look up. The caret marks the first character that could not be accepted; the thing that is actually wrong is usually the end of the previous line, or the previous value. A missing closing brace is the extreme case — it is reported at the end of the file, however far away that is.

There is no standard for a JSON parse error. Chrome and Node say "at position 42" and, in recent versions, add a line and column. Firefox gives a line and column and no position. Safari sometimes gives neither.

This page takes the character offset where one is available and works out the line and column itself, so the answer is the same in every browser rather than whatever the local engine happened to phrase. Where a message carries neither, it says so instead of guessing — a wrong line number in a long file costs more time than no line number at all.

It means the document is syntactically JSON: the brackets balance, the strings are quoted and escaped properly, the numbers are numbers. That is what a parser checks, and it is what fails when something rejects your file with an unhelpful error.

It does not mean the document is the right shape. Whether it has the fields an API expects, whether a value is in range, whether a date is a date — that is schema validation, and it needs a schema. If your JSON parses here and is still being rejected, the problem has moved from syntax to semantics and the error you are chasing will be a different one.

A trailing comma before a closing brace or bracket — legal in JavaScript, legal in JSON5, not legal in JSON, and the reason most people arrive here. A single quotation mark where JSON requires a double one. An unescaped quotation mark or backslash inside a string, which usually comes from pasting a Windows path. And a comment, which JSON does not have at all.

The fifth, rarer and harder to see, is an unescaped control character inside a string — a literal newline or tab that was pasted in rather than written as an escape. It is invisible in most editors, and it is worth suspecting when the caret is pointing at something that looks entirely fine.

The top-level type, the number of keys counted across the whole document, how deeply it nests, and its size in bytes. They are there because "valid" on its own is a yes with nothing behind it, and because each of the four is the answer to a question somebody actually has.

Nesting depth is the one worth watching. Anything past about six levels is usually a data model that grew rather than one that was designed, and it is a reliable predictor that whatever consumes the document will be awkward to write. Keys counted by occurrence rather than by distinct name answer a different question: how much is in here, not how many field names there are.