Common JSON syntax errors and how to fix them

JSON looks like JavaScript, but its grammar is much stricter. These are the mistakes that cause most "Unexpected token" errors, and how to correct each one.

Why JSON is stricter than it looks

JSON was designed as a small, unambiguous data format that every programming language can parse the same way. To achieve that, its grammar leaves out many conveniences that JavaScript, Python or YAML allow. A file that looks perfectly reasonable to a person can therefore be rejected by a parser with a short message such as Unexpected token, Expected property name or Unexpected end of JSON input.

The quickest way to find the problem is to paste the text into a JSON formatter and validator. The error message usually names a position. Look at that position and at the character just before it, because the real mistake is often one step earlier than where the parser gave up.

1. Trailing commas

JavaScript and many modern languages allow a comma after the last item in a list. JSON does not.

{
  "name": "Ada",
  "skills": ["Python", "SQL",],
}

Remove the comma after "SQL" and the comma after the closing bracket. Trailing commas are the single most common error in hand-edited configuration files, because adding and deleting lines in an editor leaves them behind.

2. Single quotes

JSON strings and keys must use double quotes. {'name': 'Ada'} is valid in Python and JavaScript, but not in JSON. Replace each single quote that delimits a string with a double quote. If the text itself contains a double quote, escape it with a backslash: "He said \"hello\"". An apostrophe inside a double-quoted string, as in "O'Brien", does not need escaping.

3. Unquoted keys

JavaScript object literals allow {name: "Ada"}. In JSON every key is a string and must be quoted: {"name": "Ada"}. This error often appears when someone copies an object from source code or from the browser console into a request body.

4. Comments

JSON has no comment syntax. Both // note and /* note */ cause a parse error. Some tools, including the TypeScript compiler and VS Code settings files, accept a relaxed format often called JSONC that permits comments, but a standard JSON parser does not. If you need to document a JSON file, use a separate README, a field such as "description", or switch to a format such as YAML that supports comments.

5. Values that JSON does not support

JSON values are limited to strings, numbers, true, false, null, objects and arrays. The following are not allowed:

• undefined. Remove the property or use null.
• NaN, Infinity and -Infinity. Use null or a string, and document what it means.
• Dates as objects. Write them as strings, preferably in ISO 8601 format such as "2026-11-07T09:30:00Z".
• Numbers with leading zeros such as 007, a leading plus sign, or hexadecimal such as 0xFF. Use 7 and 255, or a string if the leading zeros matter, as in postal codes.

6. Unescaped control characters and backslashes

A literal line break inside a string is invalid. Write it as \n. Tabs must be written as \t. A single backslash starts an escape sequence, so a Windows path must double each backslash: "C:\\Users\\ada". A path written as "C:\new" is not an error, but it silently contains a newline character instead of \n.

7. Missing or mismatched brackets

An object that opens with { must close with }, and an array that opens with [ must close with ]. When a document is long, a missing bracket produces an error at the very end of the input, far away from the real cause. Formatting the part that does parse, or removing sections until the error disappears, helps narrow it down. Many editors also highlight matching brackets.

8. More than one value at the top level

A JSON document contains exactly one top-level value. Two objects written one after another, {"a":1}{"b":2}, are invalid. Wrap them in an array, [{"a":1},{"b":2}]. Note that some logging systems produce *JSON Lines*, where each line is a separate JSON document. That format is valid line by line, but the file as a whole is not a single JSON document.

9. Invisible characters

Text copied from word processors, chat applications or web pages can contain characters you cannot see: curly "smart" quotes instead of straight quotes, non-breaking spaces, or a byte-order mark at the start of a file. A parser treats these as unexpected tokens. If the error points to a place that looks correct, retype the quotes around it or paste the text into a plain-text editor first.

A checklist for stubborn errors

1. Read the position in the error message and inspect the character before it.
2. Search the text for ',, ,] and ,} to find trailing commas.
3. Search for single quotes and //.
4. Check that each { and [ has a matching closing character.
5. Make sure the document has a single top-level value.
6. Retype quotes that may have been converted to typographic quotes.

Once the document parses, it is worth comparing it with a known good version using a JSON diff to confirm the fix did not change anything else.

Tools for this task