Douglas Crockford Wrote the JSON Spec on One Page. The Trailing Comma Has Been Breaking Things Ever Since.
Douglas Crockford was working on a data interchange problem in 2001. His team at State Software needed a way to pass data between a browser and a server without using a plugin. XML was the established option, but it was verbose and its parsing in early JavaScript was awkward. Crockford looked at what JavaScript objects already looked like: key-value pairs, arrays, strings, numbers, booleans, and null. He wrote a simple grammar for a subset of JavaScript that could represent structured data. He called it JavaScript Object Notation.
He registered json.org and put the specification online. It fit on a single page. There were no committees, no working groups, no multi-year standardization process. It spread rapidly because it solved a real problem with a simple format developers already understood from the language they were writing.
Crockford has said in interviews that he considers himself to have "discovered" JSON rather than invented it, because the object literal notation was already part of JavaScript. His contribution was identifying the subset, naming it, and promoting it. The format worked partly because JavaScript's eval() function, in the browsers of 2001, could parse a JSON string directly, making implementation trivially simple on the client side. The security implications of using eval() for this purpose would eventually lead to dedicated JSON parsers, but the simplicity drove initial adoption.
The Path to Formal Standardization
RFC 4627, the first formal Internet Engineering Task Force document describing JSON, was published in July 2006, five years after the format began spreading through the web development community. It was authored by Crockford and established JSON as an IETF-recognized data format without making major changes to the design.
ECMA International, the standards body that also maintains the ECMAScript specification for JavaScript, published ECMA-404 as the first ECMA JSON standard in October 2013. The same year, RFC 7159 superseded RFC 4627, tightening several ambiguities in the original specification. RFC 8259, published in December 2017 and currently in force, is the definitive IETF specification. It is notably short: the relevant content fits in about eight pages. Both ECMA-404 and RFC 8259 were developed in coordination to ensure the two specifications remained consistent.
The brevity of the specification is intentional and consequential. JSON has exactly six value types: strings, numbers, booleans (true and false), null, arrays, and objects. It has no dates, no undefined, no binary data, no comments, no function references. Every type that is not in this list must be represented as one of the types that is, or serialized in a way that consuming code can interpret. Dates are typically represented as strings in ISO 8601 format. Binary data is typically encoded as Base64 and represented as a string. The simplicity that makes JSON easy to parse is also the source of these workarounds.
Why JSON Breaks in Ways That Are Hard to See
JSON syntax is deliberately minimal, which means a single misplaced character can invalidate an entire document. The rules are strict: strings must use double quotes, not single. Object keys must be quoted strings. Trailing commas after the last element in an object or array are not allowed. Comments are not allowed at all. Numbers cannot have leading zeros. The value null is lowercase.
Most of these rules are not enforced by text editors. A developer can write valid-looking JSON that fails to parse, and the error message from a JSON parser is often unhelpful. "Unexpected token at position 4,731" identifies where the parser gave up, not where the problem is, and in a large document those two locations can be far apart.
The trailing comma is probably the most common source of JSON errors in practice. Most programming languages allow trailing commas in arrays and function argument lists as a convenience that makes it easier to reorder items and reduces diff noise in version control. Developers who work in JavaScript, Python, Rust, and other languages that permit trailing commas frequently make this mistake in JSON files, because the habit is correct in those languages and incorrect in JSON. JavaScript itself, since ES5, has allowed trailing commas in array and object literals; it is a source of persistent frustration that JSON, which takes its name from JavaScript, does not.
Why JSON Has No Comments
The second most common source of confusion is the absence of comments. JSON has no comment syntax. A developer trying to document a configuration file cannot write an explanation alongside a value. Crockford has explained his reasoning publicly: JSON was designed as a data format, not a configuration format, and data should not need comments. If your data requires comments to be understood, he argues, you have a design problem in the data structure.
The practical response to this position has been the emergence of several JSON extensions. JSON5 adds comments, trailing commas, single-quoted strings, and other conveniences, but it requires JSON5-specific parsers and is not accepted by standard JSON tooling. HJSON, designed specifically for configuration files, adds comments and allows multi-line strings. Both extensions solve real problems, and both create interoperability issues because they produce files that standard JSON parsers reject.
Many teams that need comment support in configuration files use YAML instead, accepting YAML's whitespace sensitivity in exchange for comment support. Others use TOML, which was created by Tom Preston-Werner, a GitHub co-founder, specifically as a comment-supporting alternative to YAML for configuration files.
Formatting as Communication and Debugging Tool
Beyond validation, JSON formatting is about readability. Minified JSON is compact and appropriate for network transmission. Indented JSON is essential for code review, debugging, and understanding unfamiliar API responses. The standard indentation convention is two or four spaces. Neither is more correct; both are in widespread use.
A well-formatted JSON document shows its structure at a glance. Nesting depth is visible. Arrays are distinguishable from objects by their bracket type. Large documents can be navigated without counting braces. When debugging an API response or editing a configuration file, formatted JSON reduces the cognitive load of parsing structure and lets the reader focus on content.
The jq tool, a command-line JSON processor created by Stephen Dolan and first released in 2012, added a layer of power beyond formatting. jq can query, filter, transform, and restructure JSON data using a compact expression language. It is widely used in shell scripts and CI pipelines to extract specific values from API responses or restructure JSON between systems. For developers working with JSON in automation contexts, jq fills the gap between a formatter and a full programming language.
Conclusion
The practice of formatting and validating JSON before working with it is defensive rather than pedantic, because a JSON error in a production system is often invisible until something depends on the value that was not parsed correctly.
ToolHQ's JSON formatter both validates syntax and applies consistent indentation, which are the two things most needed when working with unfamiliar JSON data from an API, a configuration file, or another developer's output.
Frequently Asked Questions
Why does JSON not allow trailing commas?
JSON was designed as a minimal data interchange format in 2001. Crockford deliberately excluded trailing commas, comments, and other conveniences to keep the spec simple and parsers fast. The strictness is intentional.
Why does JSON not allow comments?
Crockford designed JSON as a data format, not a configuration format. He argued that comments in data are a sign the data is being misused. JSON5 and HJSON extend the spec to add comments, but they require separate parsers.
What is the difference between minified and formatted JSON?
Both contain identical data. Minified JSON removes all whitespace and newlines to minimize file size for network transfer. Formatted JSON adds indentation and newlines for human readability.
What causes most JSON parse errors?
Trailing commas after the last element, single-quoted strings instead of double-quoted, and missing or extra braces are the most common causes. Error messages often point to where parsing failed, not where the mistake is.
Try These Free Tools
URL Encoder / Decoder
Encode and decode URLs and query strings. Escape special characters for safe URL usage.
Base64 Encoder / Decoder
Encode and decode Base64 strings online. Also supports file to Base64 encoding for data URIs.
JWT Decoder
Decode and inspect JSON Web Tokens (JWT). View header, payload, and signature without verification.