Common JSON Errors and How to Fix Them

JSON looks like a relaxed cousin of a JavaScript object, but its grammar is much stricter. Most "invalid JSON" errors come from a handful of habits that JavaScript allows and JSON does not. Paste the text into the JSON formatter and it will point at the spot where parsing stopped, which is usually enough to find the problem.

This guide walks through the mistakes that show up most often, why each one is illegal, and what to write instead. The rules come from the JSON standard, RFC 8259.

Read the error position first

A parser reads from left to right and stops at the first character it cannot accept. The position it reports is therefore where things went wrong, but the real cause can sit slightly earlier. A missing comma on line 4 is only noticed when the parser meets the next key on line 5.

Message wording differs between languages and engines, so do not rely on exact phrases. Look at the reported line and column, then check the character just before it. Often the culprit is a missing or extra comma, quote or bracket.

The most common syntax mistakes

Trailing commas

This is the single most common error:

{
  "name": "Asha",
  "tags": ["a", "b",],
}

JSON does not allow a comma after the last item of an object or array. Both commas in that example are illegal. Remove them:

{
  "name": "Asha",
  "tags": ["a", "b"]
}

Trailing commas are easy to create when you reorder lines or delete the last entry, so check the end of every list after editing.

Single quotes and unquoted keys

JSON strings must use double quotes, and object keys are strings. Each of these fails:

{ 'city': 'Pune' }
{ city: "Pune" }

The fix is to quote every key and every string value with straight double quotes:

{ "city": "Pune" }

Watch out for curly "smart" quotes as well. They often sneak in when JSON is copied from a word processor, a chat window or a web page. They look similar but are different characters, and the parser rejects them.

Comments are not allowed

You may be tempted to annotate a configuration file:

{
  // timeout in seconds
  "timeout": 30
}

Standard JSON has no comment syntax at all. Some tools accept comments as an extension, but you cannot count on it. If you need a note, either remove it before parsing or store it as data, for example a key named "timeoutNote". If you want comments in a configuration file, consider whether a format that supports them suits you better; the article on JSON vs XML vs YAML compares the options.

Values that JavaScript has but JSON does not

JSON has six kinds of value: objects, arrays, strings, numbers, true/false and null. Anything else is invalid. The usual offenders:

• undefined has no JSON equivalent. Use null or omit the key.
• NaN and Infinity are not valid numbers. Use null, a string, or leave the key out.
• Dates have no special type. Write them as strings, commonly in ISO 8601 form such as "2026-10-03".
• Functions cannot be represented.

Numbers also have their own rules. A leading zero such as 007 is not allowed, a plus sign such as +5 is not allowed, and a decimal point must have digits on both sides, so .5 and 5. both fail. Write 0.5 and 5.0, or simply 5.

Unescaped characters inside strings

Inside a string, the double quote, the backslash and any control character (including a real line break) must be escaped. Compare:

{ "path": "C:\temp\new", "note": "line one
line two" }

That text has two problems. The backslashes start escape sequences, and \t and \n would be read as a tab and a newline instead of what you meant. The raw line break inside the string is also forbidden. The corrected version:

{ "path": "C:\\temp\\new", "note": "line one\nline two" }

Remember the escape pairs you need most: \" for a quote, \\ for a backslash and \n for a newline. A bad escape such as \q is rejected, because only a fixed set of escapes exists.

When your own code produces the JSON, call the language's serializer, such as JSON.stringify in JavaScript, instead of pasting text together yourself. The serializer applies every escape rule for you, so a stray quote in a user's name cannot break the document.

Structure problems: brackets, commas and extra data

Three structural mistakes are worth knowing:

1. Missing comma between items. Two entries side by side with nothing between them fail to parse.
2. Mismatched brackets. Every opening brace or bracket needs the matching closer, in the right order. Good formatters indent nested levels so an unbalanced block stands out.
3. More than one value at the top level. Two objects pasted one after another, as in {"a":1}{"b":2}, is not one JSON document. Wrap the objects in an array and separate them with a comma, or parse them one at a time.

Log files sometimes store one JSON object per line. That is a convenient convention but each line is a separate document, so the whole file will not parse as a single one.

Invisible and encoding problems

Sometimes the text looks perfect and still fails. Possible reasons:

• A byte order mark (BOM) at the start of the file. Some editors add it, and some parsers refuse it.
• Non-breaking spaces or other unusual whitespace characters copied from a web page. JSON permits only space, tab, line feed and carriage return as whitespace between tokens.
• The wrong text encoding. The standard says JSON exchanged between systems should use UTF-8.
• An empty string or a response that is actually an HTML error page. If the first character is not a brace, bracket, quote, digit or one of the literals, look at what the server really returned.

Duplicate keys

A repeated key, such as two "id" entries in one object, is not strictly a syntax error, but the standard says names should be unique and warns that behaviour varies between implementations. One parser may keep the first value and another the last. Treat duplicates as a bug and remove them.

Quick checklist

Run through this list when parsing fails:

• Is there a comma after the last item in any object or array?
• Are all strings and keys wrapped in straight double quotes?
• Are there comments, undefined, NaN or Infinity in the text?
• Are numbers free of leading zeros, plus signs and bare decimal points?
• Are backslashes, quotes and line breaks inside strings escaped?
• Do the brackets balance, and is there exactly one top-level value?
• Could a BOM, odd whitespace or a non-JSON response be involved?

Related tools

When you need to check or tidy a document, the JSON formatter validates it, reports where parsing fails and pretty-prints the result. If a value inside your JSON is a token or an encoded blob, the Base64 encoder and decoder can unwrap it, and the guide on what a JWT is explains one common case where JSON hides inside an encoded string.