Why is my JSON invalid? The most common errors

JSON is stricter than JavaScript

JSON looks like a JavaScript object, and that is the root of most trouble: things that are perfectly valid in JavaScript are not valid in JSON. The format is defined by RFC 8259 and is deliberately small. JSON.parse() follows that grammar, and MDN notes that it throws a SyntaxError as soon as a string does not conform to it.

All the examples below fail in JSON.parse(). We checked each one in a current Node.js.

1. A trailing comma

{ "name": "Ana", "age": 31, }

The comma after the last member is the single most common error. JavaScript, many editors and even some config formats allow it; JSON does not. The same goes for arrays: [1, 2, 3, ] is invalid. MDN lists both cases as examples of illegal JSON.

2. Single quotes

{ 'name': 'Ana' }

JSON strings must be delimited by double quotes. Single quotes are invalid, for keys and for values. If you are writing JSON inside a JavaScript string, use single quotes for the JavaScript string and keep the double quotes inside, or escape them.

3. Keys without quotes

{ name: "Ana" }

In JSON every key is a string, so it needs double quotes. Unquoted keys are valid JavaScript, which is why they sneak in when someone copies an object literal from code.

4. Comments

{ "name": "Ana" /* the user */ }

The JSON grammar has no comments, neither // nor /* */. Config files that "allow comments" are using a superset such as JSONC or JSON5, not JSON itself. Strip the comments before parsing, or move the note into a field of its own.

5. NaN, Infinity, undefined and Python values

{ "ratio": NaN, "limit": Infinity, "x": undefined }

RFC 8259 says it directly: numeric values that cannot be represented in the number grammar, such as Infinity and NaN, are not permitted. undefined is not a JSON value at all. Use null, or leave the field out. (JSON.stringify does the same in the other direction: it turns NaN and Infinity into null and drops properties whose value is undefined.) The same applies to Python's True, False and None, which show up when someone pastes the output of print() instead of json.dumps(): JSON needs lowercase true, false and null.

6. Numbers written the wrong way

{ "a": 01, "b": +1, "c": .5, "d": 5., "e": 0x1F }

The number grammar is narrow: no leading zeros, no plus sign, a digit is required on each side of the decimal point and hexadecimal is not allowed. All five values above are invalid. This one often comes from IDs or zip codes with leading zeros: if the leading zero matters, store the value as a string ("01234").

7. A missing comma (or an extra one)

{ "a": 1 "b": 2 }

Members need a comma between them. This is typical when you paste a new line into the middle of an object and forget to add the comma to the line before. The parser usually points at the start of the second key, not at the place where the comma should be.

8. Raw line breaks or tabs inside a string

A string cannot contain an actual newline or tab character; they have to be written as the escape sequences \n and \t. A multi-line text pasted straight between the quotes will break the parse. Characters below U+0020 must be escaped.

9. Curly quotes and other invisible troublemakers

If you copy JSON from a document, an email or a chat, the straight quotes may have been replaced by curly ones (“ ”), which look nearly identical and are not valid delimiters. The same goes for non-breaking spaces and zero-width characters. A byte order mark (BOM) at the very start of the file can also trigger an error: RFC 8259 says implementations must not add one to network-transmitted JSON text. If a document looks right but fails, paste it into a plain-text view or the JSON formatter and validator and look at where the parser stops.

10. Truncated or empty input

"Unexpected end of JSON input" means the text ended before the structure was complete: a missing closing brace or bracket, or an empty string where JSON was expected. Check that the response was not cut off (a failed network request, a size limit) and that you are not parsing an empty body.

Two things that are valid, and surprise people

• A bare value is valid JSON. 42, "hi" and null are complete JSON texts. A JSON document does not have to be an object or an array.
• Duplicate keys are valid, but dangerous. { "a": 1, "a": 2 } parses. But RFC 8259 says the names within an object SHOULD be unique, and when they are not, the behaviour of the software receiving it is unpredictable. Many parsers keep the last value; do not rely on it.

How to find the error fast

1. Paste the text into the JSON formatter and validator. It reports the line and column where parsing stops and explains the problem in plain words, and it works in your browser, so you can paste JSON that contains real data without uploading it. If the intent is obvious, its automatic repair fixes the usual suspects (trailing commas, single quotes, unquoted keys, comments, Python values, curly quotes) and tells you what it changed; review the result, because a repair is a reasonable guess, not a guarantee.
2. Look before the reported position, not just at it: a missing comma or quote is usually reported at the next token.
3. Once it parses, use compare two JSON files to see exactly what changed between two versions, or the minifier when you need it compact.
4. If the goal is a spreadsheet, convert it with JSON to CSV once it is valid.

If the JSON ends up in a spreadsheet, how to open a CSV in Excel fixes accents and delimiters; and if it carries tokens or encoded data, how to read a JWT and what Base64 is explain how to interpret them.

Sources and further reading

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• MDN: JSON.parse() (illegal JSON examples)

Figures checked on 3 October 2026.