What Are the Most Common JSON Syntax Errors and How Do You Fix Them?

JSON syntax errors are usually boring little punctuation mistakes: a missing comma, a stray quote, an unquoted key, or a trailing comma that should never have been there. The fastest way to catch them is to paste the payload into our free JSON validator and let the parser point at the exact byte where things went sideways.

JSON is strict on purpose. It does not guess, auto-correct, or forgive much, so one wrong character can invalidate the whole document. Once you know the common failure modes, fixing them is usually a 30-second job instead of a half-hour stare-down.

Why JSON breaks so easily

JSON has a tiny grammar. Objects use curly braces, arrays use square brackets, strings use double quotes, and values can only be numbers, strings, booleans, null, objects, or arrays.

That simplicity is the trap. Developers often confuse JSON with JavaScript object literals, YAML, or whatever their framework quietly accepts, then get hit by a parser error when the payload reaches a stricter system.

The rule of thumb: if a human can read it and still think “that looks fine,” JSON may still reject it. Machines care about exact punctuation, not intent.

The errors that show up most often

Some JSON syntax errors appear over and over. They are usually obvious once you know the pattern, but they are also easy to miss when you are scanning a large payload.

• Trailing commas: JSON does not allow a comma after the last item in an object or array. {"name":"Ada",} and [1,2,3,] are invalid.
• Unquoted property names: keys must be strings in double quotes. {name:"Ada"} must become {"name":"Ada"}.
• Single quotes: JSON strings cannot use '. Use double quotes for keys and values.
• Missing colons or commas: {"a" "b"} and {"a":1 "b":2} both fail because the separator is wrong or missing.
• Bad literals: only true, false, and null are valid keywords. Capitalised versions like True or NULL are not JSON.
• Broken escape sequences: a backslash starts an escape, so ", \, \n, and friends must be valid. A lone backslash at the end of a string is a classic parser choke point.

If the document is large, the real error is often not the line the parser highlights. It is the line before it: an unclosed string, a missing brace, or a comma in the wrong place can make the next line look guilty.

Double quotes, escaping, and character traps

JSON strings are enclosed in double quotes only. If your data contains a literal double quote, it must be escaped as \"; if it contains a backslash, it must be escaped as \\.

Newlines inside strings are another common surprise. You cannot just press Enter in the middle of a JSON string and hope for the best; use \n if the value needs a line break.

This is where copied content tends to break. Text pulled from email, a doc, or a Slack message often carries smart quotes, tabs, invisible control characters, or raw line breaks that do not belong in JSON. If you suspect that kind of damage, our guide on why invisible whitespace breaks so many things in code and data is worth a look.

JSON is not being difficult. It is being exact.

That exactness is useful. A parser can validate data reliably only when the grammar is unambiguous, which is why JSON is still a default choice for APIs and config payloads.

Debugging strategy that actually saves time

When a payload fails, do not start by rewriting the whole thing. Start by checking the smallest surface area where the parser could have stopped: the line number, the character position, and the surrounding punctuation.

1. Look at the error message first. Many parsers tell you the line and column where the failure was detected.
2. Check the preceding token. Missing commas and colons usually break the next item, not the one that caused it.
3. Strip the payload down. Remove blocks until the error disappears, then add them back until it returns.
4. Validate incrementally. Paste a small valid object first, then layer in arrays, nested objects, and escaped strings.

This is why a browser validator is useful even when you already have an editor with syntax highlighting. It isolates the format problem from the rest of your stack and gives you a clean parse result without touching your codebase.

JSON versus JavaScript object literals

A lot of bugs happen because something looks like JSON but is actually JavaScript syntax. JavaScript object literals allow unquoted keys in many cases, single quotes for strings, comments, trailing commas, and expressions as values. JSON does not.

These are not interchangeable:

{name: 'Ada', active: true}

That works as a JavaScript object literal. It is not valid JSON because the key is unquoted and the string uses single quotes.

The JSON version is stricter and plain:

{"name": "Ada", "active": true}

If you are moving data between front-end code and an API, this distinction matters. A payload can look fine in your console and still explode when it hits a JSON parser on the server.

Keep the data shape boring

Most parser failures get easier when your data shape is simple. Use arrays for ordered lists, objects for keyed values, and keep strings free of formatting noise unless the data really needs it.

Nested structures are fine, but they should be deliberate. If a value is a number, keep it a number. If a field can be null, make that explicit rather than smuggling in an empty string and hoping downstream code interprets it correctly.

When you are moving data around, format it first, then validate it. If the structure is hard to read, it is harder to debug. Tools like json-format and json-minifier can help when you need to inspect or compact a payload, but the validator is the one that tells you whether the grammar is actually legal.

A Worked Example

Here is a realistic API payload that fails for a few different reasons at once. The parser does not care that the intent is sensible; it only sees broken syntax.

{
  "user": {
    "id": 42,
    "name": "Ada Lovelace",
    "roles": ["admin", "editor",],
    "active": True,
    "bio": "Enjoys analytical engines and "clean" data"
  }
}

There are three issues here. The array has a trailing comma, the boolean uses True instead of true, and the bio string contains unescaped quotes around clean.

Now fix it step by step:

{
  "user": {
    "id": 42,
    "name": "Ada Lovelace",
    "roles": ["admin", "editor"],
    "active": true,
    "bio": "Enjoys analytical engines and \"clean\" data"
  }
}

That version is valid JSON. If you paste both versions into a validator, the broken one will usually fail near the first syntax issue it encounters, which makes the bug easy to isolate. The trick is not to fix everything blindly; it is to fix the first thing the parser can no longer understand.

Frequently Asked Questions

Why does JSON reject trailing commas?

JSON is designed to be unambiguous and simple for parsers, so trailing commas are excluded from the grammar. Some JavaScript engines allow them in object literals and arrays, but JSON itself does not. If you need valid JSON, remove the comma after the last item.

How do I find the exact line causing a JSON parse error?

Use the line and column reported by the parser as a starting point, then inspect the token just before that position. Often the real issue is an earlier missing comma, colon, or closing quote. A validator makes this much faster because it pinpoints where parsing stopped.

Can JSON use single quotes for strings?

No. JSON strings must use double quotes, including quoted keys. Single quotes are fine in some programming languages, but they are not part of JSON syntax. If you see them in a payload, it is probably JavaScript object notation, not JSON.

What is the difference between invalid JSON and valid JSON with bad data?

Invalid JSON breaks the grammar, so the parser cannot read the document at all. Valid JSON with bad data still parses, but the values are wrong for your application, such as a string where a number should be. A validator checks syntax, not business rules.

The Bottom Line

Most JSON syntax errors come down to a short list of repeat offenders: trailing commas, unquoted keys, wrong quotes, missing separators, bad literals, and broken escapes. Once you learn those patterns, the fix is usually mechanical.

When the payload gets messy, stop guessing and validate it directly. Paste it into the JSON validator, clean up the first broken token, and work forward from there. It is a lot less glamorous than debugging by instinct, but it gets the job done.

If you are dealing with data that came from an API, a config file, or a copy-paste from somewhere noisy, validate early and often. JSON is strict, but that strictness is what makes it reliable once the syntax is right.