Skip to main content
riqo.ioTools for big ideas

JSON: syntax, types, structure and validation

A complete guide to JSON as a data-interchange format: grammar, types, parsing, serialization, validation and interoperability.

What JSON is and why it is widespread

JSON, JavaScript Object Notation, is a text format for structured data. It is language-independent in practice and is widely used for APIs, configuration, interchange files and lightweight persistence.

Its small grammar maps naturally to objects, dictionaries, lists and scalar values. That simplicity does not remove the distinction between syntactic validity, an expected structure and application-level meaning.

Objects, arrays and value types

A JSON document is one value: object, array, string, number, boolean or null. Objects contain string-keyed name/value members; arrays are ordered sequences and may freely nest any other JSON value.

JSON has no native date, UUID, binary or arbitrary-precision decimal type. Those meanings are conventions defined by an application, such as ISO 8601 strings for dates or a textual encoding for binary data.

Syntax rules that matter

Strings use double quotes, members are separated by commas and trailing commas are not allowed. The literals true, false and null are lowercase. Escape sequences represent quotes, backslashes and control characters inside strings.

JSON numbers exclude NaN and Infinity, and runtimes do not all preserve the same precision for large values. A document can therefore be valid JSON yet still lose numeric information in a consumer with a narrower number model.

Parsing, serialization and round trips

Parsing converts JSON text into program data; serialization does the reverse. Pretty printing and minification alter whitespace representation without changing the logical JSON value.

Reliable round trips require care with numbers, object-member ordering, Unicode and application types. Object-key order should not carry domain meaning, while array element order is structurally significant.

Syntax validity versus structural validation

Valid JSON first means that the text follows the JSON grammar. It does not prove that required fields exist, values belong to the expected domain or an API request is semantically acceptable.

JSON Schema can express richer constraints such as required properties, types, patterns, ranges and schema composition. Business validation remains separate when it depends on databases, permissions or domain rules.

Common errors and interoperability

Typical mistakes include single quotes, trailing commas, comments, unquoted keys and non-standard literals. Some permissive parsers or adjacent formats accept these constructs, but standard JSON does not.

For cross-system exchange, define UTF-8 handling, field contracts, null-versus-absent semantics, numeric limits and an evolution strategy. A readable payload is not automatically an interoperable contract.

Best practices and alternatives

Prefer predictable structures, consistent property names and versionable contracts. Document units, time zones, enumerations and optional-value behavior instead of leaving them implicit.

YAML prioritizes human-authored configuration, while XML provides namespaces, mixed content and mature schema tooling. JSON is often an excellent API format, but the right choice depends on the problem rather than popularity alone.

Related guides

JSON Schema: describing and validating data structures

How JSON Schema expresses types, properties, constraints, composition and compatibility for JSON documents.

JSON vs YAML vs XML: choosing the right format

A reasoned comparison of JSON, YAML and XML for APIs, configuration, documents, schemas and interoperability.