JSON Syntax
The complete grammar for valid JSON: the six value types, object and array structure, required string escapes, and what RFC 8259 actually specifies.
Try It Now
Put this into practice with OpenFormatter's free tools — no signup, 100% client-side.
Specification: RFC 8259's grammar defines the comma as a separator between members or values — member *( value-separator member ) — not a terminator. A trailing comma isn't explicitly forbidden so much as structurally absent from the grammar: there's no rule that produces one, so every conforming parser rejects it.
Important: Strings and object keys must use double quotes (U+0022), never single quotes. This is valid JavaScript object literal syntax but not valid JSON — RFC 8259 defines a string as beginning and ending with a quotation mark, with no alternative delimiter.
Definition
JSON syntax is the set of rules RFC 8259 defines for what counts as well-formed JSON text — six value types, how objects and arrays are structured, and how strings are escaped. A JSON parser's only job under the spec is grammar conformance: "a JSON parser MUST accept all texts that conform to the JSON grammar." Whether the *content* of a syntactically valid document makes sense for your application — whether a "price" field is actually a positive number, whether a required field is present — is a separate layer, handled by JSON Schema rather than the syntax itself. A document can be perfectly valid JSON and still be nonsense for your program; syntax and validation answer different questions.
Syntax
value = object / array / string / number / "true" / "false" / "null"
object = "{" [ member ("," member)* ] "}"
member = string ":" value
array = "[" [ value ("," value)* ] "]"Examples
One object using all six JSON value types.
{
"name": "OpenFormatter",
"version": 2,
"isFree": true,
"pricing": null,
"categories": ["json", "yaml", "xml"],
"metadata": { "clientSide": true }
}A trailing comma is invalid — the grammar has no rule for a comma with nothing after it.
// Invalid: trailing comma after the last member
{ "name": "OpenFormatter", "version": 2, }
// Valid
{ "name": "OpenFormatter", "version": 2 }Required string escapes: double quote, backslash, and control characters like newline and tab.
{
"path": "C:\\Users\\Ada",
"quote": "She said \"hello\"",
"multiline": "Line one\nLine two"
}| Type | Example | Notes |
|---|---|---|
| String | "OpenFormatter" | Double quotes required |
| Number | 42 | Integer or floating point; no separate integer type |
| Object | {} | Unordered name/value pairs |
| Array | [] | Ordered values |
| Boolean | true | "true" or "false", lowercase, unquoted |
| Null | null | Represents no value, lowercase, unquoted |
Common Mistakes
Leaving object keys unquoted
JavaScript allows unquoted identifier keys in object literals ({ name: "Ada" }), and JSON is easy to mistake for the same syntax since it was derived from it.
Fix: Every JSON key is itself a string and must be double-quoted, with no exceptions: { "name": "Ada" }.
Official Specification
Related References
FAQs
How is JSON syntax different from a JavaScript object literal?
JavaScript object literals are more permissive than JSON: they allow unquoted identifier keys, single-quoted strings, trailing commas (in modern JS), comments, and values like undefined and functions that have no JSON equivalent. JSON is a strict subset of that syntax (with one historical exception around U+2028/U+2029, covered on the What is JSON? page) — every valid JSON document is a valid JS object literal, but not the reverse.