Common JSON Syntax Errors and How to Fix Them

SyntaxError: Unexpected token } in JSON at position 1847. No filename, no line, no hint about what it wanted instead. JSON error messages are famously unhelpful, and the reported position is often nowhere near the actual mistake.

The good news is that the error space is small. JSON has a tiny grammar, and virtually every parse failure in the wild comes down to one of eight causes — nearly all of them a developer writing JavaScript or Python from muscle memory instead of JSON. This post walks through each one, what the error message tends to look like, and the fix. For the underlying rules, The Complete Guide to JSON covers the full grammar.

1. Trailing commas

The champion. JavaScript, Python, Rust, and Go all let you leave a comma after the last item so that adding a line later is a one-line diff. JSON does not.

{
  "name": "Ada",
  "role": "admin",
}

That comma after "admin" makes the document invalid. The parser consumes the comma, expects another key-value pair, and finds } instead — hence Unexpected token }. The same applies to arrays: [1, 2, 3,] fails with Unexpected token ].

Fix: delete the comma before every } and ]. If you edit JSON by hand often, turn on a JSON linter in your editor so it flags this as you type.

2. Unquoted keys

{ name: "Ada" }

This is a perfectly good JavaScript object literal and completely invalid JSON. In JSON, every key is a string, and every string is double-quoted — no exceptions, not even for keys that look like identifiers.

Typical message: Unexpected token n in JSON at position 2. The parser is inside an object, it wants a ", and it got a letter.

Fix: quote every key. This error usually arrives when someone copies an object out of a .js file, a browser console log, or a code sample and expects it to parse as JSON.

3. Single-quoted strings

{ 'name': 'Ada' }

Invalid for the same reason. JSON strings use double quotes only. Single quotes are not a stylistic alternative — the grammar simply does not include them.

This one bites hardest when pasting a Python dict that was printed with print(d) rather than json.dumps(d). Python's repr uses single quotes and writes True, False, and None, so a pasted dict usually fails on several counts at once.

Fix: replace the outer quotes with double quotes. In Python, serialise properly with json.dumps() instead of printing the object.

4. Comments

{
  // the primary account holder
  "name": "Ada"
}

There is no comment syntax in JSON. Neither // nor /* */ is legal, and a compliant parser rejects both immediately with something like Unexpected token /.

Douglas Crockford removed comments deliberately: people were using them to carry parsing directives, which broke interoperability. The consequence is that JSON is a poor format for hand-edited configuration where you want to explain a setting.

Fix: if you need annotated config, use JSONC (what VS Code accepts in settings.json and tsconfig.json), JSON5, or YAML, and strip comments in a build step before anything strict parses the file. If you must stay in pure JSON, a "_comment" key is an ugly but valid workaround.

5. Wrong literals: True, None, NaN, undefined

JSON has exactly three bare literals, all lowercase: true, false, null. Everything else fails:

• True / False / None — Python capitalisation
• undefined — JavaScript only
• NaN, Infinity, -Infinity — not representable; JSON numbers must be finite
• 0xFF, 1_000, .5, +7, 01 — hex, separators, leading dot, leading plus, and leading zeros are all invalid number forms

Error messages here vary a lot: Unexpected token T, Unexpected number, or a complaint about an unexpected identifier.

Fix: lowercase the booleans and null. For non-finite numbers, decide on a convention — null is the common choice, and JavaScript's JSON.stringify already does this — and document it, because a client that receives null where it expected a number needs to handle it.

6. Unescaped characters inside strings

A raw double quote ends the string early:

{ "quote": "She said "hello" loudly" }

The parser reads the value as "She said ", then finds the bare word hello where it expected a comma. Same class of problem: a single backslash in a Windows path ("C:\Users\ada") starts an invalid escape sequence, and a literal newline inside a string is forbidden outright — control characters below U+0020 must be escaped.

Fix: escape it. \" for a quote, \\ for a backslash, \n for a newline, \t for a tab. The complete list of valid escapes is short — \", \\, \/, \b, \f, \n, \r, \t, and \uXXXX — and anything else after a backslash, such as \x41 or \', is a syntax error. JSON escape characters explained goes through the rules and the surrogate-pair trap for emoji.

7. Mismatched or missing brackets

This is the one where the error position lies to you. A missing } does not become a problem where you omitted it — it becomes a problem at the end of the document, or wherever the nesting finally becomes impossible. On a 2,000-line file, the reported line can be hundreds of lines from the real mistake.

Common message: Unexpected end of JSON input, which means the document ended while the parser was still inside an object or array.

Fix: format the document first. Indentation makes an unbalanced structure visible, because a block that should close at column 2 suddenly sits at column 4. Editors with bracket matching help too — put the cursor on the outermost { and see where it thinks the pair is.

8. Invisible characters

The frustrating category: the document looks correct, and it still will not parse.

• Byte order mark. A UTF-8 BOM at the start of a file is three bytes before the opening {. Many parsers reject it. Symptom: an error at position 0 on a file that is obviously fine.
• Smart quotes. Text pasted from a word processor, a chat client, or a design doc often carries " and " instead of ". They render nearly identically and are not string delimiters in JSON.
• Non-breaking spaces and zero-width characters. Copied from web pages, invisible in most editors, and not valid JSON whitespace.

Fix: re-save the file as UTF-8 without BOM, and retype suspicious quotes rather than trusting them. If you suspect an invisible character, enabling "render whitespace" in your editor or running the file through hexdump -C | head will show what is actually there.

The fastest diagnostic loop

Reading JSON character by character is a bad use of your time. Let a parser do it.

Paste the document into a JSON Validator and it will report the first failure with a line and column. Remember that the location is where the grammar broke, not necessarily where you typed the wrong thing — for the bracket and escape cases especially, look upward from the reported position. A JSON Formatter is the natural second step: if it indents the document, the syntax is sound, and the indentation itself often exposes a structural mistake at a glance.

Once the document parses but the shape is wrong rather than the syntax, switch tools again. A JSON Tree Viewer renders the structure as a collapsible tree, which is how you spot that a field you expected to be an array of objects is actually a single object — a modelling problem rather than a syntax one, covered in JSON arrays vs objects.

All three run entirely in your browser. That matters more than it sounds: the JSON you most urgently need to debug is usually a live API response containing a bearer token, a customer email, or an internal schema you are not allowed to paste into someone else's server. Client-side tools let you debug the real payload instead of a sanitised copy that does not reproduce the bug.

Prevention beats debugging

Three habits eliminate most of this. Never hand-write JSON a program could serialise for you — json.dumps and JSON.stringify cannot produce a trailing comma or an unescaped quote. Enable JSON linting in your editor so errors surface as you type. And validate JSON in CI, so a broken config fails the build rather than the deployment.