Finding a JSON Syntax Error by Line Number

Finding a JSON Syntax Error by Line Number

Browser engines disagree about how to describe a broken JSON document. Chrome and Edge typically report a raw character offset, Firefox reports a line and column, and Safari often names only the unexpected token without locating it at all.¹ None of those messages, taken alone, reliably tells you where to look inside a 500-line file.

Turning a raw character offset into a place you can find

A character offset like "position 4821" is technically precise and practically useless without counting through thousands of characters by hand. When the parser reports only an offset, this tool walks your input, counts every newline up to that position, and derives the exact line and column itself, so a number that meant nothing on its own becomes a location you can navigate to directly.

Firefox already reports a line and column natively, so in that case the tool reads the values straight from the error text instead of recomputing them. Either path lands on the same normalized result: one line number and one column number, regardless of which browser rendered the page. That consistency matters more once you start comparing errors across a team using different browsers for local development.

From a number to a selected line

That normalized location feeds the "Jump to error" action. Clicking it focuses the input field and selects the entire offending line, moving your cursor to the exact spot the fix belongs rather than leaving you to scroll and re-scan the file yourself. The moment you land there, you can make the one-character fix and move straight to re-validating without losing your place in a long document.

The handful of mistakes behind almost every parse failure

In practice, four mistakes account for the overwhelming majority of JSON syntax errors: a trailing comma after the last member, a missing comma between two members, an unquoted object key, and single quotes where the grammar demands double quotes. Each one is a one-character slip rather than a structural misunderstanding, which is exactly why locating the exact line matters more than understanding JSON grammar in the abstract.

A trailing comma is the easiest to demonstrate. Paste {"a": 1,} and the validator points at the comma immediately after 1, because JSON.parse treats a comma with nothing following it as invalid, unlike a JavaScript object literal, which tolerates it.² Removing that single character produces valid JSON on the very next keystroke, and the same one-character-fix pattern holds for the other three common mistakes as well.

Reading the token name before you read the line

Knowing which of the four you are looking at before you even reach the line narrows your search immediately: an "unexpected token" pointing at a letter usually means an unquoted key, while one pointing at a closing brace or bracket usually means a trailing comma just before it. Matching the symptom to the mistake before you even look saves a full read-through of the surrounding syntax.

When the reported line is not where the real mistake lives

Occasionally the line a parser reports is not the line where the actual mistake was made. A missing comma, for instance, gets reported at the start of the *next* member, since that is the exact point where the parser expected a comma and found something else instead. The real fix belongs one line earlier, at the end of the previous member.

Reading one line past the reported error

Consequently, when the "Jump to error" line looks syntactically fine on its own, check the line immediately above it before assuming the tool made a mistake. Yet this pattern is predictable enough that once you have seen it once, spotting a missing-comma error at the reported position becomes fast: look up, not down, for what is actually missing.

Expect one fix per pass, not all of them at once. JSON.parse stops at the very first syntax error it encounters and never looks further into the document, so a file with three separate mistakes reports only the first one on your initial paste.³ Fixing that first error and re-checking is not extra work the tool is making you do; it is the only order in which a strict parser can ever report a second mistake it has not reached yet.

A file with several unrelated errors therefore takes several passes to fully clean up, and each pass is faster than the last simply because there is less document left to break. Treat a second error appearing after your first fix as normal progress, not as a sign the first fix went wrong.

When to use this

Use this guide any time a browser or build tool throws a JSON parse error and you need to convert a raw offset or vague message into the exact line to fix.

Examples

{
  "name": "widget"
  "price": 9.99
}

The parser reports the error on the "price" line, but the actual fix is adding a comma to the end of the "name" line above it. The reported line is where the parser noticed the problem, not always where the missing character belongs.

Unexpected token '}', ..."color":"red",}"... is not valid JSON at position 214

The tool counts newlines up to character 214 and reports "Line 12, Column 18," then Jump to error selects that exact line so you never have to count 214 characters by hand.