Common JSON syntax errors and how to fix them safely

Start with the first reliable error

A JSON parser reads tokens in sequence, so one missing comma or quote can make later text look wrong too. Begin with the earliest reported line and column, then inspect the character just before it. After correcting one issue, validate again instead of applying a large batch of guesses. The next diagnostic may become much clearer once the parser can recover its position.

The exact wording of an error varies by parser, but the grammar does not: a JSON value is an object, array, number, string, true, false, or null. Object member names and string values use double quotes. Literal names are lowercase. Comments and trailing commas are outside RFC 8259 JSON.

Quotes, commas, and comments

JavaScript object literals and JSON look similar, but JSON is stricter. Single-quoted keys or strings are not valid JSON. Every object member needs a colon between its name and value, while adjacent members and array items need commas. A comma cannot appear after the final member or item.

{
  // profile shown in the UI
  'name': 'Ada',
  "roles": ["admin", "author",],
}

{
  "name": "Ada",
  "roles": ["admin", "author"]
}

Delete comments only if they are documentation rather than data. If the comment carries meaning that consumers need, move it into an explicitly named string field instead of discarding it. This is one reason automated repair should always produce a proposal for review, not silently overwrite the source.

Missing delimiters and invalid string escapes

Objects must close with a right brace and arrays with a right bracket. In deeply nested data, format the valid prefix mentally or use indentation around the failing area to pair each opening delimiter with its matching close. Do not add a brace at the very end until you have checked which container is actually incomplete.

Inside strings, a quotation mark and backslash must be escaped. JSON recognizes escapes for quotation mark, backslash, slash, backspace, form feed, newline, carriage return, tab, and four-hex-digit Unicode sequences. A literal control character or an invented escape such as backslash-x is invalid. A line break in a string must be represented as the two-character escape sequence backslash-n.

{
  "path": "C:\\temp\\report.json",
  "message": "first line\nsecond line",
  "quote": "She said \"ready\"."
}

Numbers and literal values have a narrow grammar

JSON uses lowercase true, false, and null. It has no undefined, NaN, or Infinity literal. Numbers cannot start with a plus sign, and a leading zero is not allowed before another integer digit. A decimal point must have digits on both sides, and an exponent marker must be followed by digits, with an optional plus or minus sign.

• Replace language-specific values only when you know the intended JSON value; null is not automatically equivalent to undefined or NaN.
• Keep very large integers as strings when exact decimal digits matter to a JavaScript consumer.
• Treat a syntactically valid number as unverified until the receiving schema or application checks its range.

Use repair as a reviewed recovery step

A conservative repair can be useful for predictable defects such as comments, simple single quotes, or trailing commas. Missing values, merged documents, truncated input, and ambiguous delimiters require inference. Save the original, inspect the reported changes, validate the repaired JSON, and then apply domain validation before using it in production.

If the text came from a generator you control, fix the serializer rather than repeatedly repairing its output. Standards-compliant serialization prevents the same error from reaching logs, APIs, fixtures, and downstream teams again.