JSON VIEW PARSER

The Entire Grammar

JSON's specification, RFC 8259, is around sixteen pages, and most of that is prose. The grammar itself fits in four rules:

document  =  one value

value     =  object | array | string | number | true | false | null

object    =  "{"  [ string ":" value  ( "," string ":" value )* ]  "}"

array     =  "["  [ value ( "," value )* ]  "]"

That is the whole language. Its smallness is the point: a grammar this constrained can be implemented correctly in any language in an afternoon, which is precisely why JSON displaced richer formats as the default for data interchange.

Note the first rule. A document is one value — not necessarily an object. 42, "hello", true and null are each complete, valid JSON documents. The older RFC 4627 required an object or array at the top level, which is why a few legacy parsers still reject a bare string.

Objects

{
  "name": "Alice",
  "age": 30,
  "address": {
    "city": "Chennai"
  }
}

• Every key must be a quoted string. Not an identifier, not a number, not a single-quoted string. {name: "Alice"} is valid JavaScript and invalid JSON.
• Keys are case sensitive. "Name" and "name" are distinct, and may coexist in one object.
• Order is not guaranteed. Objects are unordered by specification. Most parsers preserve document order, but nothing obliges them to.
• Duplicate keys are undefined behaviour. The spec permits them without saying what should happen. Nearly every parser keeps the last one and silently drops the rest — a genuinely dangerous ambiguity, discussed on the parser page.
• An empty object {} is valid. So is an object with one key and no trailing comma.

Arrays

["a", "b", "c"]
[1, "two", true, null, {"k": "v"}, [1, 2]]
[]

Arrays are ordered, and unlike objects that ordering is guaranteed — position is meaningful and every parser preserves it. Elements may be of mixed types, though in practice a heterogeneous array usually signals a design problem rather than a deliberate choice. There are no sparse arrays: you cannot skip an index, and [1, , 3] is a syntax error even though JavaScript accepts it.

Strings

Double quotes only, always. Inside a string, seven characters must be escaped with a backslash:

\"   quotation mark        \\   backslash
\/   solidus (optional)    \b   backspace
\f   form feed             \n   line feed
\r   carriage return       \t   tab

\uXXXX   any character, by four-digit hex code point

Control characters below U+0020 cannot appear literally — a real newline inside a string is a syntax error and must be written as \n. The forward slash escape is unusual in being optional: / and \/ are both legal and identical in meaning, which is why PHP's habit of emitting \/ is valid but irritating. Full detail on the escaping page.

Numbers

JSON's number format is narrower than most languages', and the restrictions catch people out:

Valid:      0    -1    3.14    1e10    1.5e-8    -0.5

Invalid:    01        leading zero
            +1        leading plus sign
            .5        needs a leading digit → 0.5
            1.        needs a trailing digit → 1.0
            0xFF      no hexadecimal
            1_000     no separators
            NaN       not a JSON value
            Infinity  not a JSON value

Two consequences worth internalising. First, there is no integer/float distinction — 1 and 1.0 are both simply numbers, and many serialisers will collapse the latter to the former, which matters if a consumer is type-sensitive.

Second, the grammar imposes no limit on precision, but implementations do. Most parsers use 64-bit floats, so integers beyond roughly 9 quadrillion are silently rounded. Transmit large IDs and monetary amounts as strings.

Literals and Whitespace

true, false and null are lowercase, always. Python developers hand-editing JSON write True and None out of muscle memory; both are syntax errors.

Whitespace — space, tab, line feed, carriage return — may appear freely between tokens and is discarded by the parser. It is significant only inside a string, where it is data. This single rule is what makes formatting and minifying safe operations.

What JSON Deliberately Lacks

These omissions are the source of most JSON friction, and each was a conscious choice:

• No comments. Removed deliberately, after they were being abused to carry parsing directives.
• No trailing commas. Valid in JavaScript, Python, JSON5 and JSONC — never in JSON.
• No date type. By overwhelming convention, dates travel as ISO 8601 strings.
• No undefined, NaN or Infinity. JSON.stringify converts the latter two to null silently, which hides upstream arithmetic bugs.
• No binary type. Binary data is Base64-encoded into a string, at a cost of roughly 33% in size.
• No references or cycles. A self-referencing structure cannot be represented, and attempting to serialise one throws.

JSON Is Not a Subset of JavaScript

A common belief, and very nearly true — but not quite. The characters U+2028 (line separator) and U+2029 (paragraph separator) are legal unescaped inside JSON strings, while older JavaScript treated them as line terminators and choked. ES2019's "JSON superset" proposal fixed this by making JavaScript accept them, so modern engines are fine. It remains a useful reminder that "it parses as JavaScript" is not the same test as "it is valid JSON".

Frequently Asked Questions