JSON Explained: Syntax, Common Errors, and How to Fix Them

JSON is a text format for structured data built from just two container types, objects and arrays, plus four scalar types, and almost every “invalid JSON” error comes from a small handful of mistakes like trailing commas, single quotes, or unquoted keys. Once you can name JSON’s data types and recognise those errors on sight, reading and fixing JSON becomes mechanical. This article walks through the full grammar, then works through the errors you will actually hit and the exact fix for each.

What data types does JSON support?

JSON supports exactly six value types, and knowing them is most of the battle. There are two structured types and four primitives:

• Object — an unordered set of key/value pairs wrapped in curly braces, for example {"id": 1}. Keys must be double-quoted strings; values can be any JSON value.
• Array — an ordered list of values wrapped in square brackets, for example [1, 2, 3]. Elements can be mixed types.
• String — text in double quotes, for example "hello". Certain characters must be escaped with a backslash.
• Number — an integer or floating-point value with no quotes, for example 42 or -3.14 or 6.022e23. There is no separate integer type and no leading-zero or hexadecimal form.
• Boolean — the literal true or false, lowercase and unquoted.
• Null — the literal null, representing the intentional absence of a value.

That is the entire type system. There is no date type, no integer-versus-float distinction, no undefined, and no function. Dates are conventionally carried as strings, usually in ISO 8601 form like "2026-01-31T09:00:00Z", and interpreted by the application, not the parser.

How is a JSON document structured?

A JSON document is a single top-level value, which in practice is almost always an object or an array. Everything nests inside that one value. Here is a compact example that uses every type at once:

{
  "id": 42,
  "name": "Ada",
  "active": true,
  "score": 9.5,
  "manager": null,
  "roles": ["admin", "editor"],
  "profile": {
    "city": "London",
    "verified": false
  }
}

Read it structurally: the outermost braces make an object; each line inside is a "key": value pair separated from the next by a comma; roles holds an array; and profile holds a nested object. Whitespace between tokens is insignificant, so you can format JSON across many indented lines for humans or collapse it onto one line for transmission without changing its meaning. Pasting a blob into a JSON formatter that pretty-prints and validates it is the fastest way to see this structure and to have the exact error location pointed out when something is wrong.

What are the most common JSON errors?

Most JSON failures are syntax slips, and nearly all of them fall into the categories below. The single biggest source of confusion is that JavaScript object literals look almost identical to JSON but permit things JSON forbids, so code that copies a JS object verbatim often produces invalid JSON.

Why do trailing commas break JSON?

A trailing comma is the comma left after the final element of an array or object, and JSON forbids it. JavaScript tolerates [1, 2, 3,] and {"a": 1,}, but a strict JSON parser rejects both. The fix is to delete the comma that sits immediately before a ] or }:

// invalid
{ "a": 1, "b": 2, }

// valid
{ "a": 1, "b": 2 }

This one bites hardest when you delete the last field of an object and forget to remove the now-dangling comma on the line above.

Why must strings use double quotes?

JSON requires double quotes for every string and every key, and single quotes are never valid. {'name': 'Ada'} is legal JavaScript but invalid JSON. Replace each single quote used as a delimiter with a double quote:

// invalid
{'name': 'Ada'}

// valid
{"name": "Ada"}

If the text itself contains a double quote, escape it with a backslash: {"quote": "She said "hi""}.

Why do keys have to be quoted?

Every object key in JSON must be a double-quoted string, so bare identifiers are invalid even though they are the norm in JavaScript. Wrap each key in double quotes:

// invalid
{ name: "Ada", age: 30 }

// valid
{ "name": "Ada", "age": 30 }

What other slips cause parse failures?

Several smaller mistakes each produce a hard error:

• Comments. JSON has no comment syntax. Lines starting with // or blocks wrapped in /* */ are invalid. Remove them or switch to a format that allows comments.
• Unescaped control characters. A literal newline, tab, or backslash inside a string must be escaped as n, t, or \. Pasting multi-line text straight into a string value is a frequent cause.
• Wrong capitalisation of literals. The keywords are lowercase: true, false, null. True, FALSE, and NULL are all invalid.
• Malformed numbers. Leading zeros (007), a trailing decimal point (5.), hex (0xFF), and NaN or Infinity are not valid JSON numbers.
• Mismatched or missing brackets. Every { needs a } and every [ needs a ]. A truncated file or an extra closing brace both fail.

Which characters must be escaped in strings?

Inside a JSON string a specific set of characters must be preceded by a backslash. This table lists them:

The forward slash may be escaped but does not have to be; the others are mandatory when they appear literally inside a string.

How do you read a JSON parser error message?

A parser error usually tells you a position, and reading it literally saves time. Messages like “Unexpected token } at position 118” or “Unexpected end of JSON input” point at where the parser gave up, which is often just after the real mistake. “Unexpected end of input” almost always means an unclosed bracket, brace, or string earlier in the document. “Unexpected token” near a comma-and-bracket pair usually means a trailing comma. When the position is not obvious, format the document so each value sits on its own line, then the offending line becomes far easier to spot.

A worked example: fixing a broken payload

Here is a realistic broken payload with several of the errors above at once:

{
  name: 'Ada',
  'roles': ['admin', 'editor',],
  active: True,
  // primary user
  bio: "line one
line two"
}

Walking through it: the keys name, roles, active, and bio are unquoted or single-quoted; the string values use single quotes; the roles array has a trailing comma; True is capitalised; there is a comment line; and the bio string contains a raw newline. The corrected version:

{
  "name": "Ada",
  "roles": ["admin", "editor"],
  "active": true,
  "bio": "line onenline two"
}

Every key and string now uses double quotes, the trailing comma is gone, true is lowercase, the comment is removed, and the newline is escaped as n.

Where should you validate JSON safely?

Validate JSON in a tool that runs entirely in your browser so the data never leaves your machine. JSON payloads routinely carry access tokens, personal data, and internal identifiers, and pasting those into a server-side validator means handing them to a third party. A client-side JSON formatter parses and pretty-prints the text locally, flags the first error with its location, and keeps the content on your device. For anything containing real credentials or customer data, that local-only guarantee is the difference between a quick check and an accidental leak.

JSON is a small format, and its strictness is a feature: because the grammar is so limited, valid JSON is unambiguous and portable across every language. Learn the six types, memorise the double-quote rule and the no-trailing-comma rule, and the vast majority of errors you will ever see resolve themselves at a glance.