I once pasted a real API response into an online JSON formatter to debug a bug at 1am, then remembered it had a live JWT in it. Nothing happened that time, but I never found out where that formatter's server actually sent my paste. That near-miss is a good excuse to walk through how we got from XML to JSON in the first place — the shift took about 15 years, not a single announcement, and it's still moving.
1998: XML 1.0 becomes a W3C Recommendation
XML 1.0 was published by the W3C in February 1998, designed as a strict, self-describing, human-and-machine-readable markup format. It became the backbone of SOAP (published 2000) and WSDL — the enterprise API stack for the next decade. Every value was wrapped in an opening and closing tag: <name>John</name> spends 17 characters saying "name" twice.
2001: Douglas Crockford specifies JSON
Douglas Crockford formalized JSON (JavaScript Object Notation) around 2001 and registered json.org the same year, describing a format already implicit in JavaScript object literal syntax. {"name": "John"} says "name" once, in 15 characters against XML's 17 for the same single field — a small gap per field that compounds fast across a payload with 50+ fields.
2006: JSON becomes an official spec — RFC 4627
JSON was formally standardized as RFC 4627 in July 2006, giving API designers a citable spec instead of a convention. Adoption stayed gradual for a few more years — most enterprise APIs were still SOAP/XML at this point.
2009: JSON gets native browser support — ECMAScript 5
ECMAScript 5, finalized in December 2009, added native JSON.parse() and JSON.stringify() to every compliant JavaScript engine. This mattered more than the spec alone: it meant zero recursive DOM parsing was needed client-side, less main-thread work, and a real responsiveness win for anything touching Interaction to Next Paint. Within a few years, Twitter and Facebook's public APIs both dropped XML support entirely in favor of JSON-only responses.
2015 onward: JSON becomes the REST default
By the mid-2010s, JSON Schema drafts were formalizing validation (something XML had via XSD from the start), and GraphQL — released by Facebook in 2015 — used JSON as its wire format by default. For the 90%+ of REST APIs shipped today, JSON is the assumed format, not a choice that gets debated per project.
Where it's headed: binary formats nibble at the edges
The next shift isn't back to XML — it's toward binary formats like Protocol Buffers and gRPC for internal service-to-service calls, where JSON's text overhead (still larger than a binary encoding, even without XML's repeated tags) costs real bytes at high request volume. Expect JSON to stay the public-facing REST default through the rest of the decade, while internal microservice traffic keeps quietly moving to binary. XML isn't going away either — it's just staying where it already won: SOAP/WSDL banking integrations running since the 2000s that cost more to replace than maintain, and document formats like Microsoft Word's .docx, which is XML under the hood.
Where your own API responses stand today
If you're maintaining an API that still round-trips through XML for legacy reasons, or you're debugging a JSON payload right now, the fastest way to check where you actually stand is to look at the raw response — but do that without pasting a live token into a server you don't control. SolveBar's JSON Formatter runs JSON.parse() and JSON.stringify() directly in your browser tab, 0 network calls, so you can check DevTools' Network tab yourself and confirm nothing left your machine. For the XML side that's still hanging around from the SOAP era, the XML Beautifier runs the same way.