JSON Syntax Errors, Explained: How to Read Them and Fix Them Fast

You paste a config file or an API response into a parser, hit "Validate," and get back something like Unexpected token } in JSON at position 47. It's technically correct and completely unhelpful if you don't know what "position 47" means or why the parser is so unforgiving in the first place. JSON parsers aren't being pedantic for no reason - the strictness is the entire point of the format - but that doesn't make the error messages any friendlier when you're staring at 40 lines of nested objects at 11pm.

Why JSON Parsers Refuse to Guess

JSON was deliberately specified as a minimal, unambiguous grammar. Every other text-based data format you've probably used - JavaScript object literals, Python dicts, YAML - has some tolerance for looseness: trailing commas, single quotes, unquoted keys, inline comments. JSON has none of that, and it's not an oversight. The whole value proposition of JSON as an interchange format is that any conforming parser, in any language, on any platform, produces the exact same structure from the exact same bytes. The instant you allow "helpful" ambiguity - should a trailing comma be ignored, or does it mean there's a missing final element? - two different parsers could reasonably disagree, and the format stops being reliable for machine-to-machine communication.

So the rules are absolute: object keys must be double-quoted strings, string values must use double quotes (never single), there is no comment syntax at all, and nothing may follow the last item in an array or object before the closing bracket. A parser that encounters any of these doesn't try to guess your intent - it stops immediately at the offending character and reports exactly where.

Reading the Error Message: Position, Not Line Number

Here's the detail that trips people up most: when a browser's JSON.parse() reports Unexpected token } in JSON at position 47, that number is a raw character offset counted from the very first character of the string you handed it - including every space, tab, and line break. It is not a line number, and it's not a column number within a line. If your JSON is one long minified string, position 47 is easy to count to. If it's pretty-printed across 30 lines with 4-space indentation, you either need an editor that shows character offsets, or you count line by line adding up each line's length plus one for the newline character.

The token name in the message matters too. Unexpected token } generally means the parser was expecting another value (often because of a trailing comma) and instead hit a closing brace. Unexpected token ' almost always means a single quote was used where JSON requires a double quote. Unexpected end of JSON input means the string ran out before every open bracket was closed - a missing closing } or ] somewhere earlier. And critically: the reported position is where the parser gave up, which is very often one or two characters after where the actual mistake lives - a missing comma on the previous line only becomes a problem when the parser reaches the next token and finds it doesn't fit.

A Worked Example

Here's a small JSON snippet with two real mistakes in it:

{
  "name": "Ava Thompson",
  "role": 'Engineer',
  "skills": ["JSON", "APIs", "Node.js",],
}

Feed this into a strict parser and you'll get an error pointing at the single quote around 'Engineer' first, because that's the earliest invalid token in the document - a bare ' isn't a valid start of any JSON value, so the parser stops right there rather than reading further and finding the trailing commas too. Fix that one first:

{
  "name": "Ava Thompson",
  "role": "Engineer",
  "skills": ["JSON", "APIs", "Node.js",],
}

Re-parse and the next error points at the trailing comma after "Node.js" - a comma with nothing after it but the closing ]. Remove that one, and then the trailing comma after the array's closing bracket (before the final }) surfaces as the next problem. The fixed, valid version:

{
  "name": "Ava Thompson",
  "role": "Engineer",
  "skills": ["JSON", "APIs", "Node.js"]
}

Notice the pattern: a strict parser reports one error at a time, at the first invalid token it hits, and stops. It doesn't give you a full list of every mistake in the document up front - which is exactly why fixing JSON often feels like whack-a-mole: fix one error, re-run, get a new error a few characters later. That's normal behavior, not a broken tool.

The Two Mistakes That Cause Most Broken JSON

In practice, nearly every "why won't this JSON parse" question boils down to one of two habits:

• 1. Copy-pasting a JavaScript object literal and assuming it's JSON. JavaScript object literals allow single-quoted strings, unquoted keys, and trailing commas - none of which are legal JSON. Code like {name: 'Ava', active: true,} is perfectly valid JS sitting in a .js file, but drop it into a field or API body that expects JSON and it fails immediately. The fix is mechanical: double-quote every key and every string value, and strip any comma that precedes a closing bracket.
• 2. Trailing commas left behind after editing. Someone deletes the last field of an object or the last item of an array during a quick edit and forgets the comma that used to separate it from the item before it is now dangling before the closing bracket. This is the single most common cause of "it worked yesterday" JSON breakage, because the file was valid before the edit and the change looks harmless at a glance.

Where to Check Your Fix

Once you've made a fix, the fastest way to confirm it's actually valid is to paste it into the JSON Parser & Formatter and hit Validate. It runs your input through the browser's native JSON.parse(), so the error you see is the same character-offset message described above - and once it parses cleanly, the same tool will format, minify, or convert it to XML or YAML in the same pass, which saves a second round trip once you know the syntax is sound.