Why Is My JSON Invalid? How to Find and Fix the Error

If a parser just told you your JSON is invalid, the cause is almost always one of six small mistakes. Here is how to spot each one, read the error message, and get back to valid JSON in under a minute. You can paste your text into the JSON Formatter at any point to see exactly where it breaks.

The six errors that actually break JSON

JSON is a deliberately small format, which is good news when you are hunting a bug: there are not many ways to break it. In practice, more than nine out of ten invalid documents fail for one of these reasons.

1. Trailing commas. A comma after the last item in an array or object is the single most common cause. JSON has no tolerance for it, even though JavaScript does.
2. Single quotes. JSON strings and keys must use double quotes. 'name' is invalid, "name" is correct. This bites anyone copying a Python dict or a JavaScript object literal.
3. Unquoted keys. {name: "Ada"} looks fine in code but is not JSON. Every key has to be a double-quoted string: {"name": "Ada"}.
4. Missing or mismatched brackets. One unclosed } or ] tips the rest of the document into nonsense and usually produces an error pointing at the very end of the file.
5. A byte-order mark or stray encoding. An invisible BOM at the start of a file, or a smart quote pasted from a word processor, looks like whitespace to you but not to the parser.
6. NaN, Infinity, or undefined. These are valid JavaScript values but not valid JSON. Numbers must be finite, and there is no undefined keyword; use null instead.

How to read "unexpected token at position N"

Most parsers report failures as a token and a position, for example: Unexpected token } in JSON at position 142. That message is more helpful than it looks. The position is a character offset from the start of the string, and the token is whatever the parser hit when it expected something else.

The trick is that the real mistake is usually just before the reported position, not at it. If the parser complains about an unexpected }, the actual problem is often a trailing comma or a missing value one line up. Jump to that character offset, then read backwards. A formatter that shows line and column numbers turns a raw offset like 142 into something you can find at a glance.

Fixing by hand vs pasting into a validator

For a short snippet you wrote yourself, fixing by hand is fastest: you already know the shape, so a missing quote or stray comma jumps out. The risk is that one fix hides another. You delete a trailing comma, save, and the parser fails three lines later on the next one.

For anything longer than a screen, or any payload you did not write, paste it into a validator instead of guessing. A good one pretty-prints the structure, highlights the exact failing character, and keeps re-checking as you edit, so you fix every error in one pass rather than one reload at a time. The JSON Formatter runs entirely in your browser, which matters when the data is a production response or anything you would rather not upload to a server.

Invalid vs fixed: a side-by-side

Here is a snippet with four of the six errors at once: single quotes, an unquoted key, a trailing comma, and undefined as a value.

{
  name: 'Ada Lovelace',
  'role': "engineer",
  "projects": 12,
  "manager": undefined,
}

Corrected, it parses cleanly:

{
  "name": "Ada Lovelace",
  "role": "engineer",
  "projects": 12,
  "manager": null
}

Every key is now a double-quoted string, the single quotes are gone, undefined became null, and the trailing comma after the last value has been removed.

Quick diagnosis table

A quick checklist before you ship

1. Run it through a strict parser or formatter once, end to end.
2. Confirm every key and string uses double quotes, never single.
3. Remove all trailing commas and any // or /* */ comments.
4. Replace NaN, Infinity, and undefined with finite numbers or null.
5. Check the first character for an invisible BOM if the start looks fine but still fails.
6. Make sure every opening bracket has a matching close.

When in doubt, go to the source. The JSON grammar is short enough to read in full and is defined in ECMA-404, the JSON Data Interchange Standard, with the same grammar mirrored as railroad diagrams at json.org. Between those two pages, every rule that a parser enforces is spelled out, so if a tool rejects your data and you disagree, that is where you settle it.