Common JSON Errors: Examples and Fixes

A reliable repair workflow

1. Preserve the original. Work on a copy, especially if the payload contains escaped text or large numbers.
2. Confirm the input is actually JSON. An HTML error page, an empty response, or the word undefined cannot be repaired as JSON punctuation.
3. Read the first error. Later errors are often consequences of the first missing quote, comma, colon, bracket, or brace.
4. Make one small change. Parse again before editing another area so you know which change mattered.
5. Format only after parsing succeeds. Indentation makes the repaired structure easier to audit, but formatting cannot infer the intended structure of invalid input.

1. Single quotes or unquoted property names

JSON strings and object member names must use double quotation marks. Single quotes are JavaScript syntax, not JSON syntax; bare names are not allowed either.

{
  status: 'ready',
  owner: "Mina"
}

{
  "status": "ready",
  "owner": "Mina"
}

Do not blindly replace every apostrophe with a double quote. An apostrophe inside text—"don't"—is ordinary string content and should remain unchanged.

2. Missing commas or colons

A comma separates adjacent members in an object and adjacent values in an array. A colon separates an object member name from its value.

{
  "name" "LiveParse",
  "features": [
    "format"
    "inspect"
  ]
}

{
  "name": "LiveParse",
  "features": [
    "format",
    "inspect"
  ]
}

If the parser highlights the opening quote of "inspect", that quote may be perfectly valid. The missing comma at the end of the previous line is what prevented a new array value from beginning.

3. Trailing commas

JSON does not permit a comma after the final object member or array item. This differs from many programming languages that allow trailing commas in source code.

{
  "regions": [
    "ap-northeast-2",
    "us-east-1",
  ],
  "enabled": true,
}

{
  "regions": [
    "ap-northeast-2",
    "us-east-1"
  ],
  "enabled": true
}

4. Mismatched or missing brackets

Objects open with { and close with }; arrays open with [ and close with ]. Deep nesting makes a missing closer hard to spot, which is why successful formatting is useful after the repair.

{
  "builds": [
    { "id": 101, "state": "passed" },
    { "id": 102, "state": "running" }
  }
}

The first closing } after the second build belongs to that inner build object. The next closer must be ] for the builds array. When the input is large, collapse or temporarily remove complete, known-good branches in a copy until the imbalance is isolated.

5. Unescaped quotes, backslashes, or control characters

A double quote inside a string must be written as \". A literal backslash must be written as \\. Line breaks inside a string use escape sequences such as \n; an actual unescaped newline cannot occur inside a JSON string.

{
  "message": "Click "Save" now"
}

{
  "message": "Click \"Save\" now"
}

File paths are a common variation. "C:\temp\logs" contains escape-like sequences and an invalid \l. The JSON source must double its backslashes: "C:\\temp\\logs". After parsing, the resulting string contains the intended single backslashes.

6. Number formats JSON does not allow

JSON numbers are deliberately narrower than the numeric syntax of many programming languages. A number cannot have a leading plus sign, an unnecessary leading zero, a missing integer before the decimal point, or a trailing decimal point. NaN and infinity are not JSON values.

Choosing between a number, string, or null is a data-model decision, not merely a syntax fix. Confirm the producer and consumer contract before changing the representation.

7. Comments and non-JSON literals

Neither // line comments nor /* block comments */ are part of JSON. The only lowercase literal names are true, false, and null. Their capitalization matters.

{
  "cache": True, // temporary
  "expires": undefined
}

{
  "cache": true,
  "expires": null
}

The fixed example assumes null correctly means “no expiry value.” If undefined was meant to mean “field not supplied,” removing the expires member may be more accurate. Syntax tools cannot decide that semantic distinction.

8. The response is not JSON at all

An error such as “unexpected token < at position 0” often means a server returned HTML—perhaps a login screen, proxy error, or 404 page—where the client expected JSON. Likewise, an empty response body cannot be passed directly to a JSON parser.

1. Inspect the HTTP status and Content-Type header.
2. Look at the raw response before calling the parser.
3. Fix authentication, routing, or server behavior at the source instead of editing the response into JSON.

A different surprise is double-encoded JSON: parsing succeeds, but the result is a string beginning with { rather than an object. That usually means a JSON string containing serialized JSON was encoded again. Correct the producer when possible; repeated parsing can hide a broken data contract.

Why the reported position can look wrong

Parser wording varies by browser, runtime, and library. One may report an absolute character position; another may report a line and column; another may name an unexpected token. Treat the location as the point where the parser could no longer continue—not a guaranteed identification of the root cause.

{
  "job": {
    "id": 913,
    "state": "queued"
    "priority": 2
  }
}

Start at "priority", scan left and upward, and ask what separator would be required before the next token. This “look one token back” habit resolves many misleading-looking messages.

After the syntax is fixed

Valid JSON can still contain the wrong type, missing required fields, out-of-range values, duplicate object names, or strings in an unexpected format. Once parsing succeeds, verify the data against application rules or a schema. The JSON parser, formatter, and validator comparison shows which tool answers which question. For the mechanics behind syntax checks, read what a JSON parser does.