JSON VIEW PARSER

Seven Types, and That Is All

JSON's type system is deliberately tiny. A value is exactly one of these:

{
  "aString":  "hello",
  "aNumber":  42,
  "anObject": { "nested": true },
  "anArray":  [1, 2, 3],
  "isTrue":   true,
  "isFalse":  false,
  "nothing":  null
}

You will see this counted as six types or seven depending on the source. The grammar treats true and false as two separate literals rather than one boolean type, so the honest answer is seven values across six conceptual categories. Nothing rests on which way you count.

What matters far more is what is not in that list — no date, no decimal, no binary, no set. Most real-world JSON friction comes from representing those absences.

Strings

A sequence of Unicode characters in double quotes. Single quotes are never valid, for keys or values.

"hello"
"with \"escaped\" quotes"
"line one\nline two"
"emoji work fine: 🎉"
"unicode escape: \u00e9 is the same as é"

Strings are where JSON puts everything it has no dedicated type for — dates, UUIDs, decimals, enumerated values, Base64 blobs. That makes strings the most overloaded type in practice, and the reason a schema is often necessary to say what a given string actually represents. Escaping rules are covered on the escaping page.

Numbers

One numeric type, covering everything. There is no separate integer and float.

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

Two properties of this type cause most of the trouble with it.

Precision is an implementation concern, not a grammar one. JSON's syntax places no limit on digits, but nearly every parser stores numbers as 64-bit floats. Integers past 2⁵³ — about 9 quadrillion — are silently rounded:

JSON.parse('{"id": 12345678901234567890}').id
// → 12345678901234567000    ← corrupted, with no error raised

Python is a notable exception, since its integers have unlimited precision — which means a Python service can be correct while a JavaScript client consuming the same payload quietly corrupts it. Send large IDs as strings.

Money should never be a JSON number. Binary floating point cannot represent most decimal fractions exactly, so 0.1 + 0.2 famously does not equal 0.3. Use a string ("19.99") parsed into a decimal type, or an integer count of minor units (1999 cents) with the scale documented.

Objects and Arrays

The two container types, and the source of JSON's ability to describe nested structures of any shape.

{ "key": "value", "nested": { "deeper": [1, 2] } }
[ "a", "b", { "mixed": true } ]

The important distinction between them is ordering. Arrays are ordered and that ordering is guaranteed — position carries meaning and every parser preserves it. Objects are unordered by specification. Most parsers happen to preserve document order, and Python and modern JavaScript both do, but nothing in the standard requires it, so code that depends on key order is relying on an accident.

Arrays may hold mixed types, and usually should not. An array whose elements have different shapes forces every consumer to type-check each item, which is a design smell rather than a feature. See JSON arrays and JSON objects for detail.

Booleans and null

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

null deserves more thought than it usually gets, because it is not the same as an absent key:

{ "middleName": null }    // known to have no middle name
{ }                        // middle name not provided

For a PATCH request the difference is decisive — null means "clear this field", omission means "leave it as it is". APIs that treat the two identically cannot express "clear this field" at all. Decide which semantics you want and document it, because clients cannot guess.

Representing What JSON Lacks

Four types you will need constantly and JSON does not provide. These are the established conventions:

Always use UTC with an explicit Z for timestamps. A local time without an offset is ambiguous, and the ambiguity surfaces as an off-by-hours bug during a daylight-saving transition — months after the code was written.

How Types Map Across Languages

Two rows repay attention. Python splits number into int and float with unlimited integer precision, so it is the one mainstream language that will not corrupt a huge ID. Go collapses every number to float64 when decoding into interface, reintroducing the same precision loss — unless you decode into a typed struct field or call UseNumber().

Frequently Asked Questions