JSON Syntax Rules Explained: Objects, Arrays, Keys, and Values

JSON looks simple, and that simplicity is the whole point. But the rules behind it are stricter than most people expect, and a single misplaced comma or curly quote is enough to make a parser reject the entire document. Understanding the grammar exactly, rather than by guesswork, is what turns JSON from a source of cryptic errors into something you can write correctly the first time.

This guide walks through the complete JSON syntax: the building blocks (objects, arrays, keys, and values), the six data types JSON supports, and the precise rules that determine whether your text is valid JSON. Every rule comes with a copy-ready example. If you are brand new to the format, the plain-English guide to JSON is a gentler starting point; this article is the reference you return to when you need the exact grammar.

The Two Building Blocks: Objects and Arrays

All JSON structure is built from two container types. Everything else nests inside them.

Objects

An object is an unordered collection of key/value pairs, wrapped in curly braces. Keys are separated from values by a colon, and pairs are separated by commas:

{ 'name': 'Ada', 'role': 'engineer', 'active': true }

Written with real JSON (double quotes are mandatory, more on that below), it looks like this:

• The whole thing is wrapped in { }.
• Each key is a string in double quotes.
• A colon links each key to its value.
• Commas separate the pairs, but there is no comma after the last one.

Arrays

An array is an ordered list of values wrapped in square brackets. The values are separated by commas and can be any type, including a mix of types:

[ 1, 2, 3 ] or [ 'red', 42, true, null ]

Arrays preserve order, so the first element is always first. Objects do not guarantee key order, so never rely on the position of a key. The two containers nest freely inside each other, which is how JSON represents complex data: an array of objects, an object whose value is an array, and so on.

The smallest piece of valid JSON is a single value, so even 42 or 'hello' on its own is technically valid JSON. In practice, most real documents are a single top-level object or array.

Keys: The Rules That Trip People Up

Keys identify the values inside an object, and they have the strictest rules in all of JSON:

• Keys must be strings. Numbers, booleans, or bare words are not allowed as keys. Even a numeric-looking key has to be quoted: { '2024': 'leap year' }.
• Keys must use double quotes. Single quotes are not valid JSON, even though they work in JavaScript object literals.
• Duplicate keys are allowed by the grammar but unwise. The specification does not forbid them, yet most parsers silently keep only the last one. Treat keys as unique.

This double-quote requirement is the single most common reason hand-written JSON fails. The string { name: 'Ada' } is a perfectly good JavaScript object but invalid JSON, because the key is unquoted and the value uses single quotes. The valid version uses double quotes on both. If you keep hitting this, our guide to common JSON mistakes that break your code covers the rest of the usual suspects.

The Six JSON Data Types

Every JSON value is exactly one of six types. There is nothing else: no dates, no functions, no undefined, no comments. Here is the complete set, with how each one is written.

Strings

Strings are wrapped in double quotes and can contain any Unicode character. Certain characters must be escaped with a backslash: the double quote (\"), the backslash itself (\\), and control characters such as newline (\n), tab (\t), and carriage return (\r). You can also write any character with a Unicode escape, for example \u00e9 for the letter e with an acute accent. Literal newlines inside a string are not allowed; they have to be escaped.

Numbers

JSON numbers are written in decimal and may include a fractional part and an exponent, like 1.5e-9. The grammar is deliberately narrow: no leading zeros (007 is invalid), no leading plus sign, no hexadecimal or octal, and crucially no NaN or Infinity. JSON also does not distinguish integers from floats, so the receiving language decides how to interpret 10 versus 10.0. If you need exact precision for very large integers, send the number as a string and parse it yourself.

Booleans and null

These three keywords are always lowercase and never quoted. Writing True, FALSE, or 'null' turns them into either an error or a plain string, which is rarely what you want. Use null to mean a field exists but has no value, which is different from leaving the key out entirely.

The Rules That Make JSON Valid

Beyond the types, a handful of structural rules decide whether a parser accepts your document. Most parse errors come from breaking one of these.

1. No trailing commas. [ 1, 2, 3, ] and { 'a': 1, } are both invalid. The comma is a separator, not a terminator.
2. No comments. JSON has no // or /* */ syntax. If you need to annotate, add a real key like '_comment'.
3. Double quotes only. This applies to every key and every string value.
4. Proper nesting. Every { needs a matching } and every [ a matching ], correctly ordered.
5. UTF-8 encoding. Modern JSON (per RFC 8259) is encoded as UTF-8.
6. No leftover characters. Anything after the top-level value, other than whitespace, is an error.

When a document breaks one of these, you typically get a message like Unexpected token pointing at the offending character. Our walkthrough on fixing JSON parse errors maps those messages back to their causes.

A Worked Example, Annotated

Here is a small but complete document that exercises every rule above. Read it as a single object whose values cover all six types:

{ 'id': 1024, 'title': 'Field notes', 'published': true, 'rating': 4.5, 'editor': null, 'tags': ['json', 'syntax'], 'author': { 'name': 'Grace', 'verified': true } }

Notice the details that make it valid: every key is double-quoted, the number 4.5 has no leading zero, true and null are lowercase, the tags array holds two strings, the author value is a nested object, and there is no trailing comma after the final pair. Swap any double quote for a single quote, add a comment, or leave a dangling comma, and a strict parser will reject the whole thing.

Whitespace and Formatting

JSON is forgiving about whitespace between tokens. Spaces, tabs, and newlines around braces, brackets, colons, and commas are ignored, which is why the same data can be written as one dense line or spread across many indented lines. Formatting is purely for humans; the parsed result is identical either way. That difference between a compact and an indented version is exactly the trade-off covered in minify vs prettify JSON. When you want to check validity and reformat in one step, paste your text into our free JSON formatter and validator and it will pinpoint any rule you have broken.

What JSON Deliberately Leaves Out

A lot of JSON confusion comes from expecting features it does not have. JSON has no native date type (dates travel as strings, usually ISO 8601), no integer-versus-float distinction, no binary type, no comments, and no way to reference another part of the document. These omissions keep the format small and portable across every language. When you need richer structure or validation guarantees, you layer a schema on top rather than changing the syntax, which is the job of JSON Schema. And if you are weighing JSON against other formats for config files or markup, JSON vs XML vs YAML compares the trade-offs.

Key Takeaways

• JSON is built from two containers: objects (key/value pairs in { }) and arrays (ordered lists in [ ]).
• There are exactly six data types: string, number, boolean, null, object, and array.
• Keys must be double-quoted strings, and so must every string value. Single quotes are never valid.
• The rules that most often break valid JSON are trailing commas, comments, and mismatched quotes.
• Numbers have no leading zeros, no plus sign, and no NaN or Infinity; true, false, and null are always lowercase.
• Whitespace and indentation are for humans only and never change the parsed data.

Get these rules into muscle memory and the vast majority of JSON errors disappear before they happen. When one slips through anyway, a validator will tell you exactly which rule you broke and where.