UtiliStudioUtiliStudio

Common JSON errors and how to fix them

A practical reference for the JSON mistakes that break parsers, with a broken and fixed example for each, how to read parse errors, and how to stop them from happening.

By UtiliStudio Team · Updated · 5 min read

How to read a JSON parse error

JSON is strict on purpose: a document either follows the grammar exactly or it does not parse at all. When parsing fails, the error message usually includes a position, given as a character offset, a line and column, or both.

The reported position is where the parser gave up, which is often just after the real mistake. If an error points at a closing brace on line 12, look at the end of line 11 first. Error wording also varies between languages and versions, and it does not always name the real cause. In Python, for example, a single-quoted key such as {'a': 1} produces a message about property names rather than quotes:

json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

The fastest way to find the problem is to paste the document into a formatter that highlights the failing line, fix the first error only, and validate again. A single missing bracket can cause a cascade of misleading follow-up errors.

Trailing commas

JavaScript, Python, and many other languages allow a comma after the last item in an object or array. JSON does not. This is the most common error in hand-edited configuration files.

Broken
{
  "name": "UtiliStudio",
  "tags": ["json", "tools",],
}
Fixed
{
  "name": "UtiliStudio",
  "tags": ["json", "tools"]
}

Single quotes instead of double quotes

JSON strings and keys must use straight double quotes. Single quotes are valid in JavaScript and Python literals, so this error often appears when someone prints a Python dictionary or copies a JavaScript object and treats it as JSON.

Broken
{'status': 'active', 'count': 3}
Fixed
{"status": "active", "count": 3}

In Python, convert data with json.dumps(data) instead of str(data). In JavaScript, use JSON.stringify(value). Both always produce valid double-quoted JSON.

Unquoted keys

Every object key in JSON is a string and must be quoted, even when it looks like a simple identifier.

Broken
{ id: 42, enabled: true }
Fixed
{ "id": 42, "enabled": true }

Comments

Standard JSON has no comment syntax, so // and /* */ lines break strict parsers. Some tools accept comments in their own configuration files, such as tsconfig.json and VS Code settings, which use a variant often called JSONC. That does not make comments valid JSON for other programs.

Broken
{
  // retry three times
  "retries": 3
}
Fixed: move the note into data, or into documentation
{
  "retries": 3,
  "_comment": "retry three times"
}

If a file genuinely needs comments, consider a format designed for it, such as YAML or TOML, and convert it to JSON at build time.

Missing commas and colons

Items in arrays and members in objects must be separated by commas, and every key needs a colon before its value. These are easy to lose when lines are moved or merged.

Broken
{
  "first": "Ada"
  "last" "Lovelace"
}
Fixed
{
  "first": "Ada",
  "last": "Lovelace"
}

Unclosed brackets and braces

Every { needs a matching } and every [ a matching ], closed in the right order. Errors such as "unexpected end of input" usually mean something was never closed, often because a response was cut off or a file was truncated.

Indentation is your best tool here. Format the document; where the indentation suddenly drifts left or right, the unbalanced bracket is usually just above that point. If the JSON came from a network response, also check that the full response was received.

Invalid escapes and raw line breaks in strings

Inside a JSON string, a backslash starts an escape sequence, and only a few are allowed: \", \\, \/, \b, \f, \n, \r, \t, and \u followed by four hex digits. Raw control characters, including an actual line break or tab, are not allowed inside strings.

Windows file paths are a classic trap: a single backslash before a letter either creates an invalid escape or silently becomes a different character, such as a newline.

Broken
{ "path": "C:\Users\ada\notes.txt" }
Fixed
{ "path": "C:\\Users\\ada\\notes.txt" }

Values JSON does not support

JSON has exactly six value types: object, array, string, number, the literals true and false, and null. JavaScript-specific values such as undefined, NaN, Infinity, functions, and dates have no JSON representation.

  • undefined, NaN, and Infinity written into a document make it invalid.
  • JSON.stringify drops object properties whose value is undefined and turns NaN and Infinity into null, which can hide data problems.
  • Dates become strings through toJSON(), such as "2026-10-18T09:30:00.000Z". Parse them back explicitly; JSON will not do it for you.
  • The literals must be lowercase: True, False, and None from Python are invalid.

Number format mistakes

JSON numbers are decimal only. Leading zeros (007), a leading plus sign (+1), a bare decimal point (.5 or 5.), and hexadecimal (0xFF) are all invalid. Write 7, 1, 0.5, and 255, or store the value as a string if the exact formatting matters, as with postal codes and phone numbers.

A related silent problem is precision. JavaScript stores numbers as 64-bit floats, so integers above 9,007,199,254,740,991 lose precision when parsed. Large database IDs are often sent as strings for this reason.

Smart quotes and invisible characters

Copying JSON from a word processor, chat app, or web page can replace straight quotes with curly “smart” quotes. They look almost identical but are different characters, and parsers reject them.

Other invisible troublemakers include non-breaking spaces and a byte order mark (BOM) at the start of a file saved by some Windows editors. JSON.parse in JavaScript, for example, fails on a leading BOM. If a document looks correct but will not parse, retype the quotes near the error and save the file as UTF-8 without a BOM.

Multiple documents in one file

A JSON document has exactly one top-level value. Two objects one after another are not valid JSON; wrap them in an array instead.

Broken
{"event": "start"}
{"event": "stop"}
Fixed
[
  {"event": "start"},
  {"event": "stop"}
]

The broken example is actually valid in a different format, newline-delimited JSON (NDJSON or JSON Lines), common in logs and data pipelines. If that is what you have, parse it line by line rather than as one document.

Double-encoded JSON

Sometimes JSON is stored inside a JSON string, with every quote escaped. Parsing once gives you a string, not an object, which leads to confusing errors later.

const raw = '"{\\"id\\": 42}"';
const once = JSON.parse(raw);   // '{"id": 42}' (still a string)
const data = JSON.parse(once);  // { id: 42 }

The real fix is upstream: find the place that serializes the data twice, usually a call to JSON.stringify on a value that was already a JSON string, and remove the extra step.

How to prevent JSON errors

  • Generate, do not hand-build. Create JSON with JSON.stringify, json.dumps, or your language’s serializer instead of concatenating strings.
  • Validate early. Run configuration files through a JSON validator in your editor or CI pipeline so mistakes never reach production.
  • Describe the expected shape. A JSON Schema catches valid-but-wrong data, such as a missing required field or a string where a number belongs.
  • Format before you debug. Pretty-printed JSON makes bracket and comma mistakes visible at a glance.
  • Choose the right format for humans. If people edit a file by hand and want comments, YAML or TOML may be a better source format.
Try it: JSON FormatterBeautify, minify and validate JSON with syntax highlighting.
Open JSON Formatter