Common JSON Errors and How to Fix Them
A debugging guide to quotation marks, commas, brackets, data types and misleading JavaScript syntax.
Keys need double quotes
Standard JSON requires object property names in double quotes. {name:"Sam"} may be accepted in JavaScript source but is not valid JSON.
Trailing commas are invalid
{"a":1,} is rejected by strict JSON parsers. Remove the comma after the final item.
Quotes inside strings must be escaped
A string containing a literal double quote needs an escape sequence such as \". Otherwise the parser thinks the string ended early.
Brackets must match
Objects use { }, arrays use [ ]. A missing or extra closing character can cause an error that appears far from the real mistake.
Syntax validity is not schema validity
A JSON document can be syntactically perfect yet still omit a required field or use the wrong type for an API. Schema or application-level validation is a separate step.
A task you can work through
Try `{ "name": "Maya", }` in JSON Formatter. The comma before the closing brace is invalid; remove it and the parser can format the object. Next try `{ name: "Maya" }`: keys need double quotes in JSON. The tool uses the browser’s JSON parser, which reports syntax errors and pretty-prints valid JSON. It does not know your application’s required field names or validate a schema.
Where this approach fails
JavaScript object literals are not automatically valid JSON. Single-quoted strings, comments, `undefined`, trailing commas and unquoted keys are common differences. A number written as `01` is invalid JSON even though it resembles a numeric value. A syntactically valid payload such as `{ "price": "free" }` can still fail an API that expects a numeric price.
Check the result before using it
On an error, inspect the nearby punctuation, quotes and braces. After formatting, compare field names and data types with the destination API’s schema. Avoid pasting secrets or production tokens into tools unless the privacy model fits your requirements; for sensitive payloads, use a local development environment.
Walk through three valid and invalid examples
Invalid: `{ "count": 3, }` has a trailing comma. Valid: `{ "count": 3 }` parses as an object containing a number. Also valid: `{ "count": "3" }` parses, but its value is a string. A formatter distinguishes the first two by syntax; only a schema or application requirement distinguishes the latter two. If an API returns an error after the JSON formatter says valid, inspect the expected names, types, allowed values and nesting.
Debug a nested payload systematically
When a large payload fails, begin with the error position from the browser parser, then inspect the nearest closing brace, bracket, quote or comma. Format smaller valid fragments if necessary, adding one property at a time until the failure returns. This reduces a 200-line search to a local change. Do not silently replace a number with a string simply to make the formatter green. Syntactic validity is necessary for JSON, but it is not proof that the data is meaningful to its recipient.
Try the related tool
Validate and pretty-print JSON. The tool page explains its implementation and limitations. Keep your original and inspect any important result.
JSON Formatter →Technical references
These external references explain the underlying formats or browser APIs. The worked examples above describe this site's specific tool behavior.