How to fix invalid JSON: the seven errors you will actually see
Fix invalid JSON step by step: trailing commas, single quotes, unquoted keys, comments, missing brackets, NaN and undefined, and BOM problems, with examples.
A JSON parser is strict by design. It accepts exactly the grammar in RFC 8259 and nothing else, so one stray comma anywhere in a 5,000-line file makes the whole document invalid. The good news is that the same few mistakes account for nearly all of the failures I see: trailing commas, single quotes, unquoted keys, comments, a missing bracket, values that JSON does not have, and an invisible byte at the start of the file. This post goes through each one with the broken text, the error you will typically get, and the fix. Error wording differs between engines, so I show the common shape and not an exact string to match.
Read the error, then find the position
Almost every parser tells you roughly where it gave up, as a character position or a line and column. That location is where the parser first saw something it could not accept, which is often just after the real mistake. If the report points at a closing brace, look at the line above it for a missing comma or an extra one. If it points at the very end of the input, something was opened and never closed.
Work on one error at a time. Fix it, validate again, and read the next message. Fixing five things by eye and re-checking once makes it harder to tell which edit helped. A validator that shows the line and column, like the Validate button in View My JSON, turns this into a quick loop, since the check runs in your browser against what you pasted.
Trailing commas
This is the most common error by a wide margin. JavaScript, Python, Go and many config formats allow a comma after the last item, so people write it by habit. JSON does not allow it. The grammar says a comma must be followed by another value or member.
The parser's complaint usually mentions an unexpected token at the closing brace or bracket, or says it expected a double-quoted property name. Remove the comma after the last member or element. If you generate JSON by hand-building strings in a loop, switch to a serializer so the separators are handled for you.
// Invalid: comma after the last member
{
"name": "Ada",
"role": "admin",
}
// Valid
{
"name": "Ada",
"role": "admin"
}Single quotes and unquoted keys
JSON strings and object keys must use double quotes. Single quotes are not an alternative, and neither is a bare identifier as a key. This usually arrives when someone copies a JavaScript object literal or a Python dict printed with print() and pastes it as JSON. Python is a particular trap: its repr of a dict uses single quotes, and True, False and None, none of which are JSON.
Typical errors read something like "Expected property name or }" or "Expecting property name enclosed in double quotes". The fix is mechanical: double quotes around every key and every string. Do not do it with a blind find and replace if your strings contain apostrophes, as in "it's", because those must stay as they are. In Python, use json.dumps rather than printing the dict.
// Invalid: single quotes, unquoted key, Python-style literal
{ 'name': 'Ada', active: True }
// Valid
{ "name": "Ada", "active": true }Comments
JSON has no comment syntax. Neither // nor /* */ is allowed anywhere, and a parser will fail at the first slash. Config files such as tsconfig.json and VS Code settings accept comments because they are parsed as JSONC, a superset, but that is a property of those tools and not of JSON itself. If the same file is fed to a plain JSON parser, it breaks.
Remove the comments before parsing. If you need to keep notes with the data, a common workaround is a dedicated key such as "_comment", which the consuming code agrees to ignore. For files that need real comments, consider a format designed for it, such as YAML or TOML, or use a JSONC-aware parser on purpose.
// Invalid
{
// connection settings
"host": "localhost", /* default */
"port": 5432
}
// Valid
{
"host": "localhost",
"port": 5432
}Missing or mismatched brackets, and truncated data
Every opening brace and bracket needs its partner. When one is missing, the error is typically "Unexpected end of JSON input" or "Expecting , delimiter" near the end of the text. The cause is often not a typing slip but truncation: a response that was cut off by a timeout, a log line that hit a length limit, or a copy that missed the last character.
Count the structure from the outside in. Format what you have; indentation makes a missing close obvious because the nesting never returns to the left margin. If the data came from a network call, check the length and the status code before editing anything, because patching a truncated response hides the real problem, which is that the data is incomplete.
// Invalid: the array is never closed
{
"users": [
{ "id": 1, "name": "Ada" },
{ "id": 2, "name": "Lin" }
}
// Valid
{
"users": [
{ "id": 1, "name": "Ada" },
{ "id": 2, "name": "Lin" }
]
}NaN, Infinity, undefined and other values JSON does not have
JSON values are limited to objects, arrays, strings, numbers, true, false and null. There is no undefined, no NaN, no Infinity, and numbers cannot have a leading plus, leading zeros like 007, a bare decimal point like .5, or hex notation. Parsers reject all of these. Python deserves a warning: its json module will happily emit NaN and Infinity by default and will also accept them when reading, so the output is not valid JSON for other tools.
In JavaScript, JSON.stringify quietly changes these values: NaN and Infinity become null, and undefined is dropped from objects or becomes null inside arrays. If you see unexpected nulls, that is why. The fix is to decide what the value should mean. Use null for missing, omit the key, or send the number as a string.
// Invalid
{ "score": NaN, "limit": Infinity, "owner": undefined, "id": 007, "ratio": .5 }
// Valid choices
{ "score": null, "limit": null, "id": 7, "ratio": 0.5 }Byte order marks, encoding, and bad escapes
Sometimes the text looks perfect and still fails at position 0. The usual cause is a byte order mark, an invisible U+FEFF at the start of the file, which some Windows editors add when saving as UTF-8 with BOM. RFC 8259 says JSON must be UTF-8 and that implementations must not add a BOM, though parsers may choose to ignore one. Many do not: JSON.parse reports an unexpected token, and Python's json.loads says it found an unexpected UTF-8 BOM. Re-save the file as UTF-8 without BOM, or read it with the utf-8-sig codec in Python.
Two related problems are raw control characters and bad escapes. A literal newline or tab inside a string is not allowed; it must be written as \n or \t. A backslash must be doubled, so Windows paths need "C:\\temp" in the JSON text. Curly "smart quotes" pasted from a word processor or chat tool look like quotes but are different characters, and the parser will not accept them in place of the straight ones.
A repeatable process for any broken payload
Paste the text into a validator and note the first reported position. Look just before it for a comma, quote or bracket problem. Fix that single thing and validate again. When it passes, format it so the structure is easy to read, then look at it in Tree or Table to confirm the data is what you expected, since valid syntax does not guarantee valid content. If the same error keeps coming back, fix the source that produces the text rather than patching each copy. View My JSON is a free web app at app.viewmyjson.com where Validate and Format are free and nothing needs an account, but the same loop works in any validator you trust.