Skip to main content

Why Is Valid-Looking JSON Rejected?

JSON is usually rejected because its actual bytes violate the grammar, even when the text looks plausible: common causes are smart quotes, trailing commas, raw control characters, invalid numbers, or a JSON string mistaken for a JSON object.

Match the parser symptom to the failing layer

SymptomLikely causeFirst check
Unexpected token < at position 0An HTML error or sign-in page arrivedInspect status, Content-Type, and raw body
Error near the final braceTrailing comma or earlier unclosed stringCheck the preceding property and quote
Parses as one long stringJSON was encoded twiceParse once, inspect the type, then decide whether a second parse is intended
Valid parser result, app still failsSchema or type mismatchCompare the parsed shape with the consumer contract

Start with the parser error, not the appearance

JSON is a data-interchange syntax, not “JavaScript object notation with anything convenient allowed.” A conforming parser expects double-quoted property names and strings, a limited set of escapes, exact literals such as true and null, and numbers that follow the JSON number grammar. Comments, single quotes, undefined, NaN, hexadecimal numbers, and a comma after the final member are not part of JSON.

The line and column in an error message are usually where the parser finally became unable to continue, not necessarily where the mistake began. An unclosed quote on one line can make the next property look wrong. Inspect a small window before the reported location and, when possible, display invisible characters or examine the raw response body rather than a formatted console preview.

Distinguish syntax, transport, and shape problems

A syntax problem means the bytes cannot be parsed as JSON. A transport problem means the program received HTML, an empty body, compressed bytes, or text in an unexpected character encoding. A shape problem happens after parsing: the JSON is valid, but the application expected an object and received an array, expected a number and received a string, or cannot find a required field. Treat those as three different investigations.

Inspect the payload in this order

  • Capture the raw body and HTTP Content-Type before copying it through another program.

  • Verify straight double quotes, lowercase literals, balanced delimiters, and no trailing commas.

  • Check whether the top-level parsed value is an object, array, string, number, boolean, or null.

  • Validate against the receiving application’s schema only after syntax parsing succeeds.

A valid-looking object with three separate errors

{
  ‘enabled’: True,
  "limit": 10,
}

The quote marks around enabled are typographic characters, True must be lowercase true, and the comma after 10 is not allowed. Correcting only the location named by the first error will reveal the next one; validators commonly stop after the first fatal syntax failure.

Repairs that can make the data worse

  • Do not repair production data by blindly replacing every single quote; apostrophes inside strings and escaped content can be corrupted.
  • Do not paste secrets, tokens, customer records, or unredacted logs into an unfamiliar validator. Use a reduced sample that preserves the failure.
  • A formatter proves syntax, not truth. Valid JSON can still contain the wrong units, stale values, or dangerous instructions.

Questions that surface during JSON debugging

Are comments allowed in JSON?

No. Some editors accept JSON-with-comments as a separate convenience format, but RFC 8259 JSON has no comment syntax.

Can a JSON document contain only a number or string?

Yes. Modern JSON grammar permits any JSON value at the top level, although a particular API may require an object or array.

Continue the investigation

Check choosing between CSV and JSON when the evidence crosses into that problem. Use the JSON Validator with a safe, non-sensitive sample to confirm the result.

Technical references used for this diagnosis