The Origin Story of JSON: From JavaScript Object Literals to Universal Format

JSON started as a pragmatic idea: reuse the familiar shape of JavaScript object literals to move structured data between servers and browsers. That simple decision gave developers a format that felt natural in code, was easy to read over the wire, and quickly proved lighter than the XML documents that dominated early web services.

The important modern detail is that JSON is no longer just "JavaScript syntax." Today it is a language-independent data format described by ECMA-404 and RFC 8259, and its rules are stricter than normal JavaScript object literals. That distinction explains many real-world bugs, especially when a JSON string must be turned into an object inside app code, CI pipelines, or API clients.

The Web Problem JSON Solved

In the late 1990s and early 2000s, web applications were becoming more interactive. Pages were no longer just documents rendered once on the server. Developers increasingly needed background requests that could fetch fresh data without a full page reload, which is the workflow later popularized as AJAX.

XML was the default answer at the time. It was expressive, standard, and well suited to document-style data, but it was also verbose and awkward for many browser-side tasks. Pulling a small set of settings or records into JavaScript often meant navigating XML nodes instead of working with plain language-native values.

For early rich web apps, that friction showed up in a few predictable ways:

• XML markup was noisy for small payloads.
• Client-side parsing was heavier than simply reading objects and arrays.
• Simple application state often became more structured than it needed to be.

From JavaScript Literal to Data Format

JSON emerged from the observation that JavaScript already had a compact, useful notation for structured data: object literals and arrays. Instead of inventing a whole new grammar, early JSON adopters reused that familiar shape for data interchange.

Douglas Crockford is the person most closely associated with formalizing and promoting JSON, but the deeper reason it spread so quickly is that developers immediately recognized it. A browser receiving a JSON payload could map it naturally to the same kinds of structures developers already used in JavaScript code.

const settings = {
  service: "billing",
  retries: 2,
  enabled: true,
  tags: ["api", "prod"]
};

RFC 8259 still describes JSON as derived from JavaScript object literals, but it also makes clear that JSON is its own format. A JSON text is a serialized value, not a blob of script. That means the rules are intentionally narrow so that parsers in different languages can agree on the result.

How JSON Became a Standard

• Early 2000s: JSON spread alongside browser-based apps that needed a simpler alternative to XML for structured data.
• July 2006: RFC 4627 formally described JSON and registered the application/json media type.
• March 2014: RFC 7159 relaxed older assumptions, including the idea that a valid JSON text had to be only an object or array.
• December 2017: RFC 8259 became the current IETF reference, kept the grammar aligned with ECMA-404, and added stronger interoperability guidance such as UTF-8 for open network exchange.
• Today: JSON is expected almost everywhere: browser APIs, REST and many GraphQL responses, config files, logs, CI/CD tooling, and document databases.

Why JSON Beat XML for Everyday APIs

JSON won most web API battles because it matched how application developers already thought about data: objects, arrays, strings, numbers, booleans, and null. It was compact enough for network use, readable enough for debugging, and simple enough that practically every language could implement a parser without a giant standards stack.

That simplicity did not make XML obsolete in every niche. XML still has strengths for heavily document-centric workflows, formal schemas, and some enterprise integrations. But for the common case of exchanging application state between services and clients, JSON fit the job more cleanly.

What the Current Standard Still Wants You to Get Right

The history matters because many present-day parsing failures happen when developers treat JSON as loose JavaScript-like text instead of a strict interchange format.

• Use a real parser, not eval(). RFC 8259 explicitly warns that eval() is an unacceptable security risk for JSON parsing.
• Prefer unique object keys. Duplicate names are legal textually, but parser behavior becomes unpredictable.
• Use UTF-8 when JSON moves between systems on open networks. That is the interoperability baseline in RFC 8259.
• Remember that JSON is text. If you need comments, dates, binary payloads, or richer typing, you usually need conventions on top of JSON or a different format.

Modern Parsing: Turning a JSON String into an Object

This is where the origin story becomes practical. Because JSON looks familiar, teams often receive it as plain text from an environment variable, API response, build parameter, or file, then need to convert it into a real object safely.

const jsonText = '{"service":"billing","retries":2}';
const config = JSON.parse(jsonText);

console.log(config.service); // "billing"
console.log(config.retries); // 2

def raw = '{"service":"billing","retries":2}'
def config = readJSON text: raw

echo "Deploying ${config.service} with ${config.retries} retries"

The common failure mode in both examples is not history, it is syntax drift: single quotes around keys, comments, trailing commas, or language-specific values that look normal in code but are not valid JSON. A JSON formatter or validator is useful precisely because it enforces the stricter rules of the data format.

The Real Legacy of JSON

JSON became universal because it captured the right amount of structure for application data without dragging in unnecessary ceremony. It was familiar enough for JavaScript developers, portable enough for every other language, and strict enough to standardize across ecosystems.

That legacy still shapes how we work. When you remember that JSON came from JavaScript object literals but is not identical to them, the format makes much more sense: it is serialized data with strict rules, not JavaScript source code that happens to look object-like.