← Back to the JSON tool

JSON Syntax Rules

Last updated: 26 September 2026

JSON is a deliberately small grammar: six value types, two container shapes, and a handful of characters with special meaning. Everything a parser can reject comes from one of those rules, so the whole language fits on one page.

The six value types

A JSON document is exactly one value at the top level. That value may be an object, an array, a string, a number, true or null — so "hello" and 42 are both valid documents, even though most people expect the outer braces.

Objects

• Written as { } containing zero or more key: value pairs separated by commas.
• Every key is a double-quoted string: {"name": "Ada"}, never {name: "Ada"} or {'name': 'Ada'}.
• No comma after the final pair. {"a": 1,} is an error.
• Keys are case-sensitive, and duplicate keys parse without an error but keep only one value — the winner depends on the parser, so never rely on duplicates.
• Objects are unordered collections by specification. If you need a stable order for comparison or diffs, sort the keys deliberately; the formatter does it recursively.

Arrays

• Written as [ ] with values separated by commas, and the same no-trailing-comma rule.
• Elements may mix types freely: [1, "one", true, null, {}, []] is legal.
• Arrays are ordered, which is what makes [ ] the right shape for a list you will index into.

Strings and escapes

A string is any Unicode text between double quotes, except that two characters cannot appear literally: the double quote itself, and the backslash. Control characters below U+007F must be escaped too.

Anything else after a backslash is invalid — \d, \x41 and \0 all fail. This is where Windows paths bite: "C:\new\report.json" parses as C: followed by an escape, so write "C:\\new\\report.json".

Numbers

• Optional minus, digits, optional fraction, optional exponent: -1.5e+7 is fine.
• No leading zeros (01 is invalid; 0 and 0.1 are fine), no trailing decimal point, no + sign, no hexadecimal, no octal, no digit separators.
• Numbers must not be quoted if you want arithmetic: "250" is a string as far as any parser is concerned, and that single mistake causes a large share of integration bugs.
• The grammar itself puts no bound on magnitude, but most parsers read numbers as IEEE-754 doubles, so integers above 2⁵³ lose precision — snowflake IDs and Twitter IDs should travel as strings.

What JSON does not have

Knowing the absences settles most arguments with an editor that seems more permissive than the parser:

• Comments — no //, no /* */. Files that need them are JSONC, common in TypeScript configs, and must be stripped before parsing.
• undefined — omit the key instead, or use null.
• Dates, binary, functions, sets, maps — encode as a string, or a base64 string, and decide the convention with whoever reads it.
• Single quotes, multiline raw strings, trailing commas — all invalid, all commonly produced by copy-pasting from JavaScript.
• Multiple values per document — one JSON value only. Newline-delimited records are NDJSON, a different format with its own parser.

The eight mistakes that cause almost every parse error

1. {"a": 1,} — trailing comma. Fix: remove it.
2. {'a': 1} — single quotes. Fix: use double quotes on both key and value.
3. {a: 1} — unquoted key. Fix: {"a": 1}.
4. // config at the top — a comment. Fix: delete it, or parse as JSONC with a tool that supports it.
5. {"ok": True} — capitalised literal. Fix: true.
6. {"v": NaN} — non-finite number. Fix: null or a string.
7. {"p": "C:\new"} — bad escape. Fix: double the backslash.
8. {“a”: 1} — smart quotes pasted from a document or slide. Fix: retype them as straight quotes.

Each of these is reported with its exact line and column by the JSON validator, along with the cause in words.

Frequently Asked Questions