Why XML Lost to JSON for Web APIs

By 2005, XML was the unquestioned lingua franca of inter-system communication on the web. SOAP 1.1 had become a W3C Note in 2000, the WS-* stack (WS-Security, WS-Addressing, WS-ReliableMessaging) promised enterprise-grade contracts, and RSS was syndicating the blogosphere. The reasoning of the era was sound: XML had a real schema language, namespaces for vocabulary mixing, mature toolchains, and a culture of formality that mirrored the CORBA and SOA worlds that big IT shops already understood. If you were Microsoft, IBM, or Oracle selling middleware, an angle-bracketed envelope was a feature, not a bug. The reversal happened on the ground rather than in a standards body. Douglas Crockford had registered json.org in 2002 and published a short, almost defiantly minimal description of JSON — a syntax he later described as something he discovered rather than invented. Three structural advantages compounded. First, verbosity: closing tags roughly double payload size for nested records, and parsing XML required pulling in heavyweight DOM or SAX libraries. Second, the impedance match with browsers: JSON deserialized into native JavaScript objects with a single call (eventually formalized as JSON.parse in ES5), while XML required DOM traversal or XPath. Third, the schema gap cut the right way for most teams — XML Schema was powerful but notoriously baroque, whereas JSON's structural simplicity meant developers could just read the response and start coding. The REST API movement, drawing on Roy Fielding's 2000 dissertation, packaged these advantages into a default posture: plain HTTP verbs, JSON bodies, no envelope. The SOAP/WS-* stack, by contrast, demanded envelopes, headers, WSDL contracts, and code generators before a single byte crossed the wire. As mobile apps and AJAX-heavy SPAs exploded between 2008 and 2014, bandwidth and developer experience both pointed the same direction. JSON was standardized as ECMA-404 and RFC 8259, won the public Web API battle, and became the default for NoSQL stores, webhooks, and config files. XML didn't die — it retreated to domains where its strengths still pay rent. SAML 2.0 assertions remain the backbone of enterprise SSO because XML Signature handles detached, canonicalized signatures that JSON ergonomics never matched cleanly. Government open data, financial reporting (XBRL), and structured publishing (JATS, DocBook, DITA) all depend on XSLT pipelines and mixed-content semantics that JSON cannot express without contortion. The lesson is that format wars are usually won by developer onboarding speed, not by feature parity — and that the loser often keeps the territories where its original design assumptions still hold.