Developer tools · JSON formatter & validator
The whole JSON grammar on one page: six value types, two containers
· Background
json standards validation
JSON's entire grammar fits on one page, and knowing it by heart makes every validator error obvious. This post walks through the six value types, the two containers, and the handful of rules that trip people up.
Every error you have ever seen comes from one page
Every syntax error is a broken expectation in a compact grammar. After an object opens, a parser expects a quoted member name or a closing brace; after a name, it expects a colon; after a value, it expects a comma or the end of the container. Reading an error as a failed transition is more useful than treating the reported character as mysterious.
ToolAcre accepts the standard JSON values and whitespace, then applies two practical input limits. Text longer than 8,000,000 characters is rejected before parsing, and scanner nesting beyond 512 containers is rejected rather than traversed indefinitely. Those are product boundaries, not new JSON types. Within them, the diagnostic identifies the first point where the token stream can no longer satisfy the grammar.
The six values — object, array, string, number, true/false and null, and the fact that there is nothing else
A JSON value is an object, array, string, number, boolean or null. Objects and arrays can contain any of the six, including more containers. The literal spellings are exactly `true`, `false` and `null`; capitalization is not flexible. Tokens such as `True`, `None`, `undefined`, `NaN` and `Infinity` are outside strict JSON even when another language recognizes some of them.
This short list makes classification a useful debugging technique. In `{"reading": NaN}`, the colon correctly introduces a value, but `N` cannot begin any permitted value. Replace it only after deciding what the data should mean, perhaps `null` or a quoted status. A syntax tool can reject the token; it cannot choose the application’s substitute or decide whether the field belongs there.
Objects and arrays — comma-separated members, the colon, and why RFC 8259 leaves ordering and duplicate names to implementations
Objects contain comma-separated name/value members. Every name is a double-quoted string followed by a colon and a value. Arrays contain comma-separated values with no names or colons. Empty `{}` and `[]` containers are valid, but a comma cannot lead, trail, or appear twice. Matching each delimiter to its container quickly exposes many apparent “unexpected token” failures.
Object names are expected to be unique, yet duplicate spelling is not rejected by this validator. `{"port": 80, "port": 443}` parses, and `JSON.parse` retains the later value. Formatting then emits only that surviving member, so the earlier text cannot be recovered from the result. Array positions behave differently: every element remains present and its order is part of the value.
Strings and numbers precisely
Strings use double quotes. A backslash may introduce a quote, backslash, slash, `b`, `f`, `n`, `r`, `t`, or four-digit Unicode escape; raw control characters are forbidden. Single quotes are ordinary invalid tokens outside a string. These rules explain why copied JavaScript literals and pasted multiline text can look readable while failing strict JSON validation.
A number may have a minus sign, an integer part, an optional fraction and an optional exponent. It cannot begin with `+`, use hexadecimal notation, carry a leading zero before another digit, or spell a non-finite value. `-0.25e+2` is valid; `01`, `.5`, `2.` and `Infinity` are not. Parsing checks grammar, not whether JavaScript can preserve every digit exactly.
Whitespace and the top level
Outside strings, JSON whitespace is limited to space, horizontal tab, line feed and carriage return. A non-breaking space copied from a web page is not interchangeable with an ordinary space. Formatting may freely choose among permitted whitespace around tokens, but it must preserve whitespace that belongs inside a quoted string because those characters are data.
The complete document may be any single JSON value, not only an object or array. `42`, `false` and `"ready"` are valid top-level texts. What is forbidden is a second value after the first: `42 43` is two documents, not one. This distinction explains why newline-delimited JSON requires record-by-record handling rather than one ordinary parse of the entire file.
Worked example: parsing a small document by hand
Take `{"order": [17, null, {"paid": true}], "note": "ship soon"}`. The root object begins a member named `order`; its value is an array containing a number, null and another object. A comma then introduces `note`, whose value is a string with an escaped newline. Every colon, comma and closing delimiter has one grammatical role.
Now remove the quote before `paid`. After the nested brace, the parser expects a closing brace or a quoted name, so it fails at `p`. Alternatively, add a comma after `true`; the parser accepts the comma and then fails at `}` because another member must follow. Predicting those positions by hand turns validation into confirmation and discourages random punctuation edits.
What this does not cover
The grammar has no date, decimal-money, binary, UUID or duration type. Applications usually represent those concepts with strings or numbers and impose conventions separately. A timestamp can be a perfectly valid JSON string while containing an impossible date. Likewise, a syntactically valid object can omit required properties or use the wrong units without violating a single parsing rule.
ToolAcre does not perform schema checks, domain validation or canonicalization. It also does not reinterpret JSON5 or JSONC features such as comments and trailing commas. Its job is narrower: accept one strict JSON text within the product limits, format the parsed value, and identify syntax failures. Keep later questions about shape and meaning in the consuming application’s validation layer.
Takeaway: memorise the grammar, trust the position
The durable checklist is short: six value categories, quoted object names, commas only between items, colons only between names and values, strict string escapes, strict number spelling, four whitespace characters and exactly one top-level value. When a document fails, identify what the grammar allowed immediately before the reported position and compare that expectation with the character actually present.
Trust the position as the first impossible point, not always the character that needs deletion. A closing brace may be highlighted because a preceding comma promised another member; an innocent letter may be highlighted because its opening quote is missing. Repair the cause, rerun validation, and repeat. For oversized or extremely deep input, address the 8-million-character or 512-depth product boundary before syntax diagnostics can help.