JSON Syntax Cheat Sheet

The six structural characters

Six punctuation characters carry all of the structure in JSON: the braces { } that wrap objects, the brackets [ ] that wrap arrays, the colon : that separates a key from its value, and the comma , that separates pairs inside an object or values inside an array. Nothing else in the grammar does structural work — every other character in a document is either inside a string or is one of the four whitespace characters. A comma is strictly a separator: it may appear between two items, never before a closing brace or bracket.

{"name":"Ada","tags":["math","pioneer"]}

{"name":"Ada","tags":["math","pioneer"],}

Whitespace: exactly four characters

Outside strings, JSON permits exactly four whitespace characters: the space (U+0020), the horizontal tab (U+0009), the line feed (U+000A) and the carriage return (U+000D). Anything else — vertical tab, form feed, non-breaking space, a byte order mark — is a syntax error, even though many editors render those characters invisibly. That is why JSON pasted from a word processor so often fails validation: the document looks clean on screen and contains characters the grammar has never heard of.

Whitespace is also what makes formatting possible. Because the grammar ignores these four characters between tokens, the same document can be one long line on the wire and an indented tree in your editor, and the two forms are semantically identical — no parser can tell them apart after reading.

{"a":1,"b":[2,3]}

{
  "a": 1,
  "b": [
    2,
    3
  ]
}

Strings: double quotes and the nine escapes

A JSON string is wrapped in double quotes — never single quotes. Inside, the backslash \ introduces an escape, and RFC 8259 defines exactly nine two-character escapes: two are mandatory, \\" for a literal double quote and \\\\ for a literal backslash, because those two characters would otherwise end or corrupt the string. Six more are optional shorthands — \/ for the forward slash and \b \f \n \r \t for the five control characters that appear most often in text. The ninth form is \uXXXX, which writes any Unicode code point by its four-digit hexadecimal number.

Every character outside the escape set may appear literally as UTF-8, and the two forms are equivalent: a parser delivers the identical string either way. Escaping is spelling, not data — a point the escaping guide develops in depth.

"quote": "she said \"hi\""
"path": "C:\\Users\\ada"
"e-acute": "\u00e9"

quote:   she said "hi"
path:    C:\Users\ada
e-acute: é

Numbers: ECMAScript, minus the extensions

A number is an integer or decimal in plain notation, with an optional exponent. RFC 8259 adopts the ECMAScript number grammar and removes its extensions: no hexadecimal, no octal, no leading zeros, no leading plus, no bare trailing dot. An exponent uses e or E with an optional sign, and the only sign a number may start with is the plain hyphen-minus. NaN, Infinity and -Infinity are not JSON — languages that have such constants write null in their place by convention.

Precision is deliberately left to implementations: the grammar says nothing about how many digits a parser must honour, so very long numbers can arrive silently changed. Interoperable producers keep integers inside the range the target platform represents exactly — for the IEEE 754 doubles behind JavaScript, that is up to 2^53 − 1.

The three literals and the five classic rejections

Three bare tokens complete the value set: true, false and null. They are lowercase and unquoted — True, FALSE and None are syntax errors, not creative capitalisation. Around them, the grammar draws five lines that account for nearly every rejected document in the wild:

• No comments. RFC 8259 has no comment syntax; // or /* */ anywhere is a syntax error. Annotate with a sibling key like "_comment" where the format is under your control.
• No trailing commas. [1, 2, 3,] and {"a":1,} are invalid, however friendly they look — the comma is a separator, and it cannot separate an item from nothing.
• No single quotes and no unquoted keys. {name:'ada'} is invalid JSON; {"name":"ada"} is the grammar's only spelling.
• No duplicate keys — officially. The grammar permits a name to appear twice, but RFC 8259 §4 leaves which value wins to implementations, so a document that relies on duplicates has no defined meaning.
• Any top-level value. Since RFC 8259, a whole document may be a bare string, number, boolean or null — RFC 4627's objects-and-arrays-only rule is gone, and "hello" or 42 are complete JSON documents.

Encoding: UTF-8 and the byte-level rules

RFC 8259 §8.1 fixes the byte encoding: JSON text exchanged between systems that are not part of a closed ecosystem must be encoded in UTF-8. There is no UTF-16 or UTF-32 JSON on the open wire, and producers must not prepend a byte order mark — a parser may ignore a leading BOM rather than error, but nothing conforming emits one. Note how the layers separate: \uXXXX escaping is a notation choice inside individual strings, while UTF-8 is a property of the whole document, and the two solve different problems.

That closes the grammar. The fastest way to make these rules permanent is to run your own documents against them — format a real payload, break one rule at a time, and read each validator error. Ten minutes of deliberate failure teaches more than another pass over this page.