Complete Guide to JSON Formatting, Validation, and Syntax

JSON's entire grammar, in full

JSON (JavaScript Object Notation) has a deliberately small grammar — six types, no more:

• Object: {"key": value, ...} — unordered key/value pairs, keys always double-quoted strings.
• Array: [value, value, ...] — ordered list, any mix of types.
• String: double-quoted only ('single quotes' are invalid JSON).
• Number: no leading zeros, no + prefix, optional decimal and exponent (-3.14e10).
• Boolean: true / false (lowercase, unquoted).
• Null: null (lowercase, unquoted).

That's the entire type system. No dates, no comments, no functions, no undefined — anything beyond these six is a convention layered on top by whoever's consuming the JSON, not part of the format itself.

The syntax rules that actually cause errors

{
  "name": "ToolSphere",
  "count": 3,
  "active": true,
  "tags": ["json", "tools"]
}

The rules that trip people up, roughly by frequency:

1. Trailing commas are invalid. {"a": 1,} fails — JavaScript object literals allow this, JSON does not.
2. Keys must be double-quoted strings. {name: "x"} is invalid JSON (valid JS), and {'name': 'x'} is too (single quotes aren't valid anywhere in JSON).
3. No comments, anywhere. Neither // nor /* */ is valid JSON — a common trap for people hand-writing config files.
4. Numbers can't have leading zeros (007 is invalid) or leading + (+5 is invalid).
5. NaN, Infinity, and undefined are not valid JSON values — even though they're valid in the JavaScript that JSON's syntax was based on.

Why "it looks right" isn't validation

A JSON document can be visually plausible and still be invalid — a stray trailing comma from a copy-paste, an unescaped quote inside a string, a duplicate key (technically legal per the spec, but most parsers silently keep only the last occurrence, discarding data). Strict validation via an actual parser catches all of these immediately; eyeballing a large document does not, especially once nesting goes more than 2–3 levels deep.

Common mistakes

• Unescaped characters inside strings. A literal " or \ inside a string value must be escaped (\", \\) — a raw newline inside a string is also invalid; it needs \n.
• Confusing JavaScript object literals with JSON. They look nearly identical but aren't the same grammar — JS allows unquoted keys, trailing commas, comments, and single quotes; JSON allows none of these.
• Assuming key order or duplicate keys are meaningful. The JSON spec doesn't guarantee key order is preserved by every parser, and behavior for duplicate keys is implementation-defined — don't rely on either.
• Silent truncation from mismatched brackets. A missing closing } or ] deep in a large nested document often produces a confusing error pointing at the end of the file rather than the actual mismatch — working from the innermost structure outward helps isolate it.

FAQ

Why does my JSON fail with a trailing comma that JavaScript accepts fine?
Because JSON's grammar is a strict subset of JavaScript object/array literal syntax — trailing commas are a JS-only convenience, not part of the JSON spec.

Can JSON have comments?
No — not in the spec. Some tools support a superset called JSON5 or JSONC (JSON with Comments) for config files, but that's a different, non-standard format, not plain JSON.

Does JSON preserve the order of object keys?
The spec doesn't require it, though in practice most modern parsers (including JavaScript's) preserve insertion order — don't rely on this across all tooling, especially older or non-JS parsers.

What happens if my JSON has duplicate keys?
The spec doesn't define behavior; most parsers keep only the last value for a repeated key and silently discard the earlier ones, which can hide data loss if you're not checking for duplicates.

Validate, format, and explore nested JSON instantly with the JSON Toolkit — parsing happens entirely in your browser.