Common JSON Errors (and How to Fix Them)

Few error messages are as familiar — or as frustrating — as "Unexpected token in JSON" or "Invalid JSON." JSON's rules are strict and unforgiving, and a single misplaced comma can break an entire payload. The good news is that almost every JSON error falls into a short, predictable list of causes. This guide walks through the common JSON errors, why each happens, and exactly how to fix it.

It is written for developers who debug JSON daily, students learning the format, and anyone who has stared at a red error message wondering what is wrong with their data.

Why JSON Is So Strict

Before the specific errors, it helps to understand why JSON is so unforgiving, because that context makes the rules feel less arbitrary. JSON was designed to be a simple, unambiguous data-interchange format that any language can parse identically. To achieve that, it deliberately has a tiny, rigid grammar with no room for the conveniences programmers are used to in their source code — no comments, no trailing commas, no optional quotes. Every parser, in every language, follows the same strict specification, which is exactly what makes JSON so reliable across systems. The flip side is that the very flexibility you enjoy when writing JavaScript object literals is forbidden in JSON, and habits carried over from code are the source of most errors.

This is the single most useful mental shift for avoiding JSON errors: JSON is data, not code. It looks like a JavaScript object, but it is a far more restricted format. Once you internalise that JSON will not tolerate the shortcuts a programming language allows, the common errors become predictable, because they nearly all stem from treating JSON as if it were as forgiving as the code around it.

In short: Most JSON errors come from treating JSON like code — trailing commas, single quotes, unquoted keys, comments, and unescaped characters. JSON's strict grammar forbids all of these, and a validator will pinpoint the exact line of the problem.

Error 1: Trailing Commas

The most common JSON error by far is the trailing comma — a comma after the last item in an array or the last pair in an object. JavaScript happily allows it, so the habit is deeply ingrained, but JSON forbids it absolutely.

// INVALID — trailing commas after the last element
{
  "name": "Ada",
  "roles": ["admin", "editor",],
  "active": true,
}

// VALID — no comma after the last item
{
  "name": "Ada",
  "roles": ["admin", "editor"],
  "active": true
}

The fix is simply to remove the comma following the final element in every array and object. When a parser reports an unexpected token near a closing bracket or brace, a trailing comma is the first thing to check.

Error 2: Single Quotes and Unquoted Keys

JSON requires double quotes for all strings and all object keys. Single quotes are not allowed anywhere, and keys must always be quoted — both of which differ from JavaScript object literals, where single quotes work and keys can often be bare.

// INVALID — single quotes and an unquoted key
{ name: 'Ada' }

// VALID — double-quoted key and value
{ "name": "Ada" }

The fix is to use double quotes for every key and every string value. This single rule eliminates two of the most frequent error categories at once. If you are copying a JavaScript object into a JSON context, this is almost always the first thing you need to correct.

Error 3: Comments

JSON has no comment syntax. Neither // line comments nor /* block comments */ are valid, even though both are second nature in code. Including a comment will break parsing immediately.

// INVALID — comments are not allowed in JSON
{
  "timeout": 30, // seconds
  "retries": 3
}

The fix is to remove all comments. If you genuinely need annotated configuration, some tools accept relaxed supersets like JSON5 or JSONC, but strict JSON — which is what APIs and most parsers expect — must contain no comments at all. A common workaround is to add a dedicated string field, such as a "_comment" key, to carry a note as actual data.

Error 4: Unescaped Special Characters

Certain characters must be escaped inside JSON strings: double quotes, backslashes, and control characters like literal newlines and tabs. Forgetting to escape them — especially a quote inside a string or a literal line break — produces invalid JSON.

// INVALID — an unescaped double quote and a literal newline
{ "quote": "She said "hello"", "note": "line1
line2" }

// VALID — escaped quote (\") and newline (\n)
{ "quote": "She said \"hello\"", "note": "line1\nline2" }

The fix is to escape embedded double quotes as \", backslashes as \\, and represent newlines and tabs with \n and \t rather than literal characters. When you build JSON programmatically with a proper serializer, this escaping is handled for you, which is one more reason to generate JSON with a library rather than by hand.

Error 5: Wrong Value Types and Literals

JSON has specific literal forms, and using a language's own conventions instead is a frequent error, particularly when hand-converting data from Python or other languages. JSON's boolean literals are lowercase true and false, and its null is lowercase null. Writing Python's True, False or None, or capitalising the JSON literals, is invalid.

// INVALID — Python-style literals
{ "active": True, "deleted": None }

// VALID — JSON literals are lowercase
{ "active": true, "deleted": null }

Numbers have rules too: JSON does not allow leading zeros (007 is invalid), and the special values NaN and Infinity are not valid JSON numbers, even though many languages produce them. The fix is to use the exact JSON literals — lowercase true, false, null — and to represent special numeric values as strings or null if they must appear at all.

Error 6: Structural Problems

Several errors come from broken structure rather than individual tokens. Missing or extra commas between elements break the grammar — every pair and array item must be separated by exactly one comma. Unbalanced brackets or braces — an opening { or [ without its matching close, or vice versa — are common in hand-edited or truncated JSON. And duplicate keys in the same object, while technically tolerated by many parsers (which usually keep the last one), are a logic error you should avoid because the behaviour is not guaranteed. The fix for these is careful attention to nesting, which is exactly where a formatter helps: re-indenting the JSON makes mismatched brackets and stray commas visually obvious.

Error 7: Invisible and Wrapper Problems

The most maddening JSON errors are the ones you cannot see. A byte-order mark (BOM) or other invisible character at the start of a file can cause a parser to reject otherwise-valid JSON. Trailing content after the JSON value, or a stray character before it, breaks parsing. And when you are consuming an API, the "JSON" you received may not be JSON at all: an error or authentication failure might return an HTML error page, a redirect, or an empty body, and your parser chokes on the unexpected content. Some APIs even prefix JSON with an anti-hijacking sequence like )]}' that must be stripped before parsing. The fix is to inspect the raw response when an inexplicable error occurs — what you think is malformed JSON is often not JSON at all, and seeing the actual bytes reveals the truth immediately.

Reading JSON Error Messages

Parsers usually tell you where the problem is, and learning to read these messages turns debugging from guesswork into a quick fix. Most errors include a position — a line and column number, or a character offset — pointing at or just after the offending token. A message like "Unexpected token } at line 5" almost always means a trailing comma on line 4, because the parser expected another item but found the closing brace. "Unexpected end of input" means the JSON is truncated or a bracket is unclosed. "Unexpected token <" famously means you received HTML (the opening of a tag) where you expected JSON. Rather than re-reading the whole document, jump to the reported location and inspect the token just before it. A JSON validator makes this even easier by highlighting the exact spot.

Try Our Free JSON Tools

The fastest way to find and fix a JSON error is to let a tool point to it. Both of ours run entirely in your browser:

• ✅ JSON Validator — checks validity and shows the exact line of any error
• ✅ JSON Formatter — re-indents JSON so structural problems become visible

👉 Validate your JSON now →

Preventing JSON Errors

The best way to deal with JSON errors is to avoid creating them, and a few habits accomplish that. Whenever possible, generate JSON with a serializer rather than building it by hand — JSON.stringify, json.dumps and their equivalents produce correct, fully escaped JSON every time, eliminating quote, comma and escaping errors at the source. When you must hand-edit JSON, use an editor with JSON syntax highlighting and linting, which flags errors as you type. And validate before you ship: run configuration files and fixtures through a validator as part of your workflow, so a stray comma is caught at your desk rather than in production. These practices turn JSON from a source of recurring frustration into a format that simply works.

Why JSON Errors Are So Common in Practice

It is worth reflecting on why these same handful of errors recur so persistently, because the reasons point toward avoiding them. The deepest cause is the close resemblance between JSON and JavaScript object literals. Because JSON looks almost identical to the object syntax developers use every day in code, the brain naturally applies the more permissive rules of the programming language to the stricter data format. Trailing commas, single quotes, unquoted keys and comments are all perfectly normal in JavaScript, so writing them in JSON feels right even though it is wrong. The very familiarity that makes JSON easy to read is what makes its errors easy to commit.

A second cause is that JSON is so often assembled or edited by hand, particularly in configuration files, test fixtures and quick experiments, where there is no serializer to enforce correctness. Hand-editing is exactly where stray commas, mismatched brackets and forgotten quotes creep in, because a human is doing the bookkeeping a library would otherwise handle flawlessly. A third cause is that JSON frequently arrives from sources outside your control — APIs, third-party services, copied snippets — where the problem may not even be in your data but in what you received, such as an HTML error page masquerading as a response. Understanding these root causes reframes JSON errors not as random misfortunes but as predictable consequences of specific situations, which is precisely why the preventive habits of generating JSON with a library, using a linting editor, and validating before shipping are so effective: each one removes a class of these situations at the source.

A Systematic Approach to Debugging JSON

When you do hit an error, a methodical approach beats staring and guessing. Begin by trusting the parser's message: it almost always reports a position, and the actual problem is usually at or just before that point, so jump straight there rather than re-reading the whole document. If the message is one of the recognisable signatures — an unexpected closing bracket pointing to a trailing comma, an unexpected end of input pointing to an unclosed structure, or an unexpected < revealing that you received HTML — you often know the cause before you even look. This habit of mapping error messages to their typical causes turns most JSON debugging into a quick, targeted fix.

If the location is not obvious, the next move is to format the JSON, because re-indenting it makes structural problems like mismatched brackets and stray commas visually apparent, and a formatter will also fail outright on invalid input and tell you so. Failing that, a validator will pinpoint the exact line and position. And when none of the data-level checks reveal a problem, step back and inspect the raw input you are actually parsing, byte for byte, because the most baffling JSON errors are the ones where the supposed JSON is not JSON at all — an empty body, an error page, a BOM, or a wrapper prefix. Working through this sequence — read the error, jump to the position, format to expose structure, validate for precision, and inspect the raw input as a last resort — resolves essentially every JSON error efficiently, replacing frustration with a reliable routine.

Common Mistakes (Summary)

1. Trailing commas after the last array or object element.
2. Single quotes or unquoted keys instead of double quotes.
3. Comments, which JSON does not support.
4. Unescaped quotes, backslashes or newlines inside strings.
5. Wrong literals — True/None instead of true/null, or leading zeros.
6. Unbalanced brackets or missing commas.
7. Invisible characters or non-JSON content like HTML error pages.

Best Practices

• Generate JSON with a library, not by hand, to avoid syntax errors entirely.
• Use double quotes everywhere and never leave a trailing comma.
• Validate JSON before using or shipping it.
• Inspect the raw response when an API returns "invalid JSON" — it may be HTML.
• Use a formatter to reveal structural problems, and an editor that lints JSON.

Frequently Asked Questions

Why is my JSON invalid?

The most common causes are trailing commas, single quotes instead of double quotes, unquoted keys, comments, unescaped special characters, and wrong literals like True or None. A JSON validator will point to the exact line of the error.

Can JSON have trailing commas?

No. Unlike JavaScript, JSON does not allow a comma after the last element in an array or object. Remove it to make the JSON valid.

Why does JSON not allow comments?

JSON was designed as a minimal data format with no comment syntax. If you need annotations, use a relaxed superset like JSON5 or JSONC, or add a dedicated string field as data; strict JSON must contain no comments.

What does "Unexpected token < in JSON" mean?

It usually means you received HTML rather than JSON — the < is the start of an HTML tag. This often happens when an API returns an error or login page instead of data. Inspect the raw response.

How do I fix unescaped characters in JSON?

Escape double quotes as \", backslashes as \\, and use \n and \t for newlines and tabs instead of literal characters. Generating JSON with a serializer handles this automatically.

How can I find where my JSON is broken?

Read the parser's error message, which usually gives a line and column, and inspect the token just before that position. A JSON validator highlights the exact location of the problem.

Summary

Almost every JSON error comes from one root cause: treating JSON like the flexible code it resembles rather than the strict data format it is. Trailing commas, single quotes, unquoted keys, comments, unescaped characters and wrong literals are all conveniences that JavaScript allows and JSON forbids, and structural slips like unbalanced brackets or stray content complete the list. The cures are equally consistent: generate JSON with a serializer instead of by hand, use double quotes and no trailing commas, escape special characters, inspect raw responses when an API surprises you, and validate before you ship. Learn to read the parser's line-and-column hints, lean on a validator and formatter to pinpoint problems, and the dreaded "Invalid JSON" becomes a quick, routine fix rather than a mystery.

👉 Find and fix JSON errors with our free tools →

Related Resources

• What Is JSON? — the fundamentals
• JSON Validation Guide — validate JSON properly
• How to Format JSON — make JSON readable
• JSON Validator — find errors instantly
• JSON Formatter — beautify and inspect JSON