How to Read a JSON Parse Error: A Practical Debugging Checklist

A JSON parse error usually points to the place where a parser could no longer continue, not necessarily to the decision that caused the malformed document. The fastest repair is to preserve the original input, use the error position as a starting point, and check the surrounding JSON structure before editing values.

This guide answers a practical question: how do you turn an error such as “unexpected token” or “expected , or }” into a small, reliable fix?

Start with the original bytes and the reported location

Copy the failing request body, file, or response before formatting or editing it. If the parser gives a line, column, offset, or an unexpected character, record that information with the source. A line number can shift after someone manually adds or removes a line, so it is most useful against the exact input that failed.

Then inspect a small window around that position:

1. Read the character immediately before the reported location.
2. Find the opening { or [ that contains it.
3. Check what the parser should expect next in that container: a property name, a colon, a value, a comma, or the closing delimiter.
4. Compare that expectation with the actual character.

For example, in this object the parser reaches "active" while still expecting a comma after the preceding value:

{
  "name": "Mina"
  "active": true
}

The repair is a comma after "Mina", not a change to the active value:

{
  "name": "Mina",
  "active": true
}

Check the JSON rules that most often cause an error

JSON has a deliberately small grammar. Its values are objects, arrays, strings, numbers, true, false, or null; objects use name/value pairs separated by commas, and arrays use comma-separated values. 1 2 3

That gives a compact first-pass checklist:

• Missing or extra comma: Put commas between object members and array elements, but not after the final member or element.
• Wrong quote character: JSON strings and object names use double quotation marks. A single-quoted JavaScript-style string is not JSON. 4
• Unquoted property name: {name: "Mina"} may work in some JavaScript contexts, but valid JSON requires "name".
• Unclosed string or container: Every ", {, and [ needs its matching closing character in the right order.
• Invalid escape: Within a JSON string, a backslash begins one of JSON’s defined escape sequences; a literal backslash must therefore be escaped as \\. 4
• A number written in a non-JSON form: JSON numbers do not permit leading zeroes, and NaN and Infinity are not JSON number values. 5

Distinguish a syntax error from a data-shape problem

Parsing answers only one question: “Is this text valid JSON?” It does not prove that an API accepts the names, types, or business meaning of the values.

These two payloads illustrate the difference:

{ "email": "mina@example.com", "subscribed": true }

{ "email": "mina@example.com", "subscribed": "true" }

Both are syntactically valid JSON. The second may still fail if the receiving API expects a Boolean rather than a string. After a parse error is fixed, compare the payload with the receiving endpoint’s documented schema or a known-good example. Do not “fix” a parsing problem by guessing at field names or types.

The same distinction applies to duplicate object names. RFC 8259 says object names SHOULD be unique and notes that software behavior is unpredictable when they are not. A parser can accept the text while another system keeps only one of the duplicated values. 6

Use formatting as a diagnostic step, not a rewrite step

Once you have preserved the input, pass a non-sensitive copy through a JSON formatter or validator. If it parses, indentation makes unmatched nesting and missing separators easier to spot. If it does not parse, keep the reported location alongside the original and make one minimal correction at a time.

yukt.tools lists JSON formatting among its online utilities. Use a formatter to make a sample readable during troubleshooting, but do not paste credentials, session tokens, personal data, or production secrets into a third-party page unless you are authorized to disclose them. The receiving system’s documentation remains the authority for its expected schema.

A practical safe loop is:

1. Keep the original request or file unchanged in a secure place.
2. Validate a redacted copy and locate the structural error.
3. Apply the smallest syntax correction.
4. Validate again.
5. Compare the resulting structure and value types with the destination’s contract.
6. Send only an authorized test payload, then retain the error and final payload as appropriate for the team’s debugging process.

Frequently asked questions

Why does the error point at a character that looks correct?

The reported character is often the first point at which the parser can prove that the grammar no longer works. The actual cause may be immediately before it, such as a missing comma, an unterminated string, or a closing bracket for the wrong container. Work backward to the preceding separator and opening delimiter before changing the reported token.

Is JavaScript object syntax always valid JSON?

No. JSON requires double-quoted strings and object names, and its number grammar does not include values such as NaN or Infinity. A JavaScript object literal can use constructs that a JSON parser must reject. 4 5

Does valid JSON mean an API will accept my request?

No. Valid JSON only establishes syntax. The API can still reject an unknown field, a missing required field, a value of the wrong type, or a value that fails its own rules. Check the endpoint’s documented request contract after the JSON parser succeeds.

Sources and research

1. RFC 8259, section 3: Values — IETF JSON specification, accessed 2026-09-28.
2. RFC 8259, section 4: Objects — IETF JSON specification, accessed 2026-09-28.
3. RFC 8259, section 5: Arrays — IETF JSON specification, accessed 2026-09-28.
4. RFC 8259, section 7: Strings — IETF JSON specification, accessed 2026-09-28.
5. RFC 8259, section 6: Numbers — IETF JSON specification, accessed 2026-09-28.
6. RFC 8259, section 4: Object name uniqueness — IETF JSON specification, accessed 2026-09-28.