JSON Syntax & Validation: The Complete Guide

The full JSON grammar, in practice

JSON has exactly six data types, and that's the entire vocabulary — nothing else is valid inside a JSON document:

• Object — { "key": value, ... }. Keys must be double-quoted strings; unquoted keys are invalid.
• Array — [ value, value, ... ]. Elements can be any mix of the six types.
• String — double-quoted only. Single quotes are never valid string delimiters.
• Number — no leading zeros (007 is invalid), no trailing decimal point without digits, no NaN or Infinity — all three are valid in JavaScript but not in JSON.
• Boolean — lowercase true / false only.
• Null — lowercase null only.

That's it. No dates, no functions, no undefined, no comments, no trailing commas — everything else a JavaScript object literal allows that isn't on this list is a JSON syntax error.

Why JSON only looks like JavaScript

JSON's syntax was deliberately modeled on JavaScript object/array literals for familiarity, but it was standardized as its own independent format (RFC 8259, and mirrored in ECMA-404) — not a JavaScript feature. JavaScript itself has since relaxed its own object literal syntax in ways JSON never adopted: modern JS allows trailing commas, unquoted identifier keys, single-quoted strings, comments, and values like undefined and NaN. None of that is valid JSON, which is exactly why copy-pasting a JS object literal into a .json file is the single most common source of "valid-looking" JSON that actually fails to parse.

The four mistakes that cause almost every parse error

• Trailing commas. {"a": 1, "b": 2,} — that comma after 2 is invalid. Easy to leave behind when reordering or deleting the last item in an object or array.
• Single-quoted strings. {'key': 'value'} — JSON requires double quotes for every string and every key, with no exceptions.
• Unquoted keys. {key: "value"} — valid as a JS identifier key, invalid in JSON; the key needs quotes too: {"key": "value"}.
• Comments. Neither // line nor /* block */ comments exist in the JSON spec at all. A stray comment left in from editing will break the entire parse, not just get ignored.

A correct version of a commonly broken example:

{
  "name": "Frost Rank",
  "tools": 13,
  "live": true
}

versus the broken JS-literal version that looks almost identical:

{
  name: 'Frost Rank',
  tools: 13,
  live: true, // trailing comma
}

Reading a "line X, column Y" error correctly

A parser reports the position where it could no longer continue matching valid JSON grammar — which is usually at or extremely close to the actual mistake, but occasionally one token later, because the parser only realizes something's wrong once it hits the next unexpected character. A missing closing brace, for instance, often gets reported at the very end of the file (where the parser ran out of input) rather than at the actual line where the brace should have been. When the reported line looks unremarkable, check the line immediately before it — that's the second most likely location. This is exactly the gap Frost Rank's JSON Formatter & Validator was built to close: it uses the same grammar JSON.parse does, with a dedicated error locator that points at the precise line and column instead of a vague browser console message.

Beautify vs. minify — and when to use each

Beautifying adds indentation and line breaks purely for human readability — useful when debugging a response body or reviewing a config file by eye. Minifying strips every unnecessary whitespace character to shrink the file size — useful for anything transmitted over a network, like an API payload or an embedded config blob, where every byte affects transfer time. The data is identical either way; only the formatting changes.

Minified JSON also hides inside other formats. The payload of a JSON Web Token is a minified JSON object encoded as Base64URL, so the same grammar rules apply to every claim in it, and a JWT decoder can unpack and beautify it in one step when you need to read one.

Frequently asked questions