Anatomy of a JSON Error: Finding the Exact Line and Column

"Is this JSON valid?" is a yes-or-no question, but "no" alone is nearly useless when you are staring at 200 lines of configuration at 5pm. A good validator answers the second question too: where exactly is the file broken, stated as a line and column you can jump to in an editor. The gap between a verdict and a coordinate is the whole difference between validation and debugging.

What "valid" actually means

Validity is a syntax property, decided by a parser. The validator hands your text to the standard JSON parser and accepts its judgment as final — no heuristics, no leniency. On success it reports a structural summary alongside the verdict: the root type (object, array, string, number, boolean or null), the number of keys or elements, and the byte size. Paste {"a":1,"b":[2,3]} and you get back object, 2 keys, 17 bytes — plus a pretty-printed copy for reading. (What those six value types are and how they nest is the ground covered in JSON explained.)

From byte position to line and column

On failure the parser throws a SyntaxError, and modern engines name the offending position in the message. The validator pins down that byte, then does simple arithmetic: count the newline characters before the position to get the line, and subtract the last newline's offset to get the column (both 1-based, matching every editor's status bar). Feed it this document:

{
  "name": "Ada",
  "tags": ["a", "b",],
  "active": true
}

and the verdict is invalid, line 3, column 21 — the exact spot where the trailing comma sits after the final array element. One subtlety: the parser reports the position where it gave up, which is at or very near the mistake but can occasionally be a character or two past it, since some errors are only detectable once the parser sees what follows.

The usual suspects

Five mistakes cause the overwhelming majority of invalid JSON, and almost all of them are habits imported from JavaScript or Python:

{ 'name': 'Ada' }    ← single quotes
{ name: "Ada" }      ← unquoted key
{ "a": 1, "b": 2, }  ← trailing comma
{ "a": 1 "b": 2 }    ← missing comma
{ "a": 1 }}          ← extra closing brace

The parser reports the first problem it hits, not all of them — fix that one, re-run, and possibly meet the next. That iterative loop is normal: one pass per error is still far faster than eyeballing a large file.

Syntax versus semantics

A validator proves your document parses, not that it is correct. {"age": "banana"} is perfectly valid JSON and perfectly wrong data. Catching that requires a schema — expected types, required keys, value ranges — which is a different tool for a different job. What syntax validation does guarantee is that every downstream consumer, from JSON.parse in a browser to a config loader in a build system, will at least be able to read the file.

Validator, formatter, minifier

The three JSON-shaping tools overlap but lead with different jobs. The formatter pretty-prints and assumes the input is valid — it is the wrong tool for a broken file, because it fails with a raw parser error and no guidance. The minifier strips whitespace for transport. The validator leads with the verdict and, on failure, the coordinates. A natural workflow runs validate first, then format: confirm the document parses, then make it readable. Since all three run entirely in the browser, there is no reason not to check before shipping a config change.

Try it yourself

Break a JSON file on purpose — swap a double quote for a single one, or add a trailing comma — and paste it into the JSON Validator to see the exact line and column it names. Fix the error, re-run, and watch the summary appear instead. Then send the clean document through the JSON Formatter for a readable copy and the JSON Minifier to see how many bytes whitespace was costing.