JSON Workshop

JSON enforces rigid syntax rules: all object keys must be double-quoted, single quotes are invalid for string representation, and trailing commas on arrays or objects are forbidden. These strict rules make JSON parsing deterministic and fast, but increase validation errors when developers write or edit JSON configurations manually.

JSON supports exactly six data types: string, number, boolean, null, object, and array — there is no native date, undefined, or binary type, which is why dates in JSON are conventionally represented as ISO 8601 strings and binary data as base64-encoded strings, both by convention rather than by the format itself.

JSON Schema is a separate specification, not part of RFC 8259 itself, for describing the expected shape of a JSON document: which properties are required, what type each value must be, and constraints like string length or numeric ranges. A JSON Schema document is itself valid JSON, describing another JSON document's structure.

Because JSON has no schema of its own, two systems exchanging JSON must agree on structure out-of-band — either through documentation, a JSON Schema definition, or, in practice often, by inferring it from example payloads, which is a common source of integration bugs when the actual data later includes an unanticipated shape.

A common task is confirming an API response or configuration file is both syntactically valid and structurally correct before your application consumes it. Start with the JSON Formatter to validate syntax and pretty-print the document for readability, catching basic errors like a trailing comma or unquoted key immediately.

If you're defining or checking a contract for what a JSON payload should contain, use the JSON Schema Generator to derive a starting schema from a real example payload, then the JSON Schema Validator to check future payloads against that schema before your application processes them — catching a malformed or unexpected payload before it causes a downstream error.

When integrating with a system that expects a different format, use the JSON ⇄ YAML Converter or JSON ⇄ CSV Converter to translate between formats, and the JSON to TOML tool when working with tools that use TOML configuration, such as many Rust and some Python project files.

For minifying a JSON payload before sending it over the wire, or for comparing two versions of a JSON document to see exactly what changed, use the JSON Minify and JSON Diff Checker tools respectively.

Mistake: assuming JSON.stringify() and JSON.parse() round-trip every JavaScript value losslessly. JSON.stringify() silently drops object keys with undefined values and function values entirely, rather than throwing an error — a common source of "my API response is missing a field" bugs that isn't actually a serialization failure, just silent omission.

Mistake: relying on JSON to preserve numeric precision for very large integers. JSON numbers map to JavaScript's double-precision floating point by default, which loses precision above 2^53 — IDs or values larger than that need to be represented as strings, not numbers, if exact precision matters.

Troubleshooting: if a JSON document that looks correct still fails to parse, check for a trailing comma after the last item in an array or object, or single quotes used instead of double quotes for strings — both are invalid JSON despite being valid in JavaScript object literals, and are the two most common hand-editing mistakes.

Troubleshooting: if a JSON Schema validation is failing in a way that seems wrong, check whether the schema enforces additionalProperties: false — this rejects any property not explicitly listed in the schema, which is correct strict behavior but a frequent source of confusion when a payload has been extended with a genuinely new, valid field the schema hasn't been updated to allow.

JSON itself is defined by RFC 8259, which also aligns with the ECMA-404 standard maintained by Ecma International — the two describe the same grammar from different standards bodies.

JSON Schema is defined by its own specification, currently at the 2020-12 draft, maintained by the JSON Schema community rather than the IETF — unlike JSON itself, it is not an RFC.

Date and time values have no native JSON type; RFC 3339, a profile of ISO 8601, is the de facto convention for representing them as strings, though it is not enforced by the JSON grammar itself.

If you need a lightweight format with universal parser support and don't need comments or advanced references, use JSON. See the JSON vs YAML comparison for when YAML's added readability and features are worth the tradeoff, and the JSON vs TOML comparison for when TOML's simpler, ini-like syntax fits configuration files better.

If you're defining a contract for an API or configuration file that multiple systems or teams need to agree on, add a JSON Schema rather than relying on documentation alone — it is both machine-validatable and can generate that documentation.

If you're deciding where JSON fits in a request/response cycle, it is almost always the payload, not the transport — see the HTTP & Web Protocols hub for the status codes, headers, and URL structure that carry the JSON payload itself.