Developer tools · JSON formatter & validator
How JSON replaced XML as the default format for web APIs
· Background
json standards validation
Twenty years ago XML was the assumed format for anything sent between systems. This post traces how JSON displaced it in web APIs, what each format was designed for, and why XML still dominates some domains.
One SOAP endpoint left
One SOAP endpoint left — an integration that speaks XML in a codebase where everything else speaks JSON, and the question of how we got here. The contrast often appears in client code: one path manages envelopes, namespaces and generated types, while newer endpoints exchange ordinary objects through lightweight HTTP libraries. That observation describes a local architecture, not a universal chronology.
The formatter handles JSON only; cross-format conversion belongs to the separate Syntax converters panel. JSON’s popularity does not make XML obsolete, nor does local pretty-printing validate an API contract. This article distinguishes historical adoption from the narrower behavior implemented on this route. Unsupported historical claims about decisive dates, causes or market-wide replacement are deliberately omitted or corrected rather than inferred from present-day defaults.
What XML was built for
What XML was built for — documents with mixed content, namespaces, schemas and transformation pipelines. Elements can contain both text and child markup, attributes can carry metadata, and namespace-qualified names let vocabularies coexist. Technologies such as XML Schema, XPath and XSLT support validation, querying and transformation across document-centered workflows.
Those capabilities are not gratuitous when the payload is a publication, signed business document or extensible industry message. They do impose more concepts than a simple object-and-array exchange requires. Comparing equivalent examples should therefore consider the contract, not merely character count: XML and JSON expose different modeling tools, and neither syntax automatically supplies correct domain semantics.
What browsers could do natively
What browsers could do natively — XMLHttpRequest could retrieve either textual format, and browsers offered XML DOM parsing. Early JavaScript code sometimes evaluated JSON-like text, an unsafe practice when input was untrusted; standardized `JSON.parse` later provided a dedicated parser. Parsed JSON maps naturally to JavaScript arrays, objects, strings, numbers, booleans and null.
That mapping reduces ceremony for many browser applications, but it is not evidence that browsers were unable to process XML or that one API alone determined adoption. XML DOMs preserve elements, attributes and namespaces rather than becoming plain objects automatically. Historical claims about causation need sources beyond implementation convenience, so unsupported versions are omitted or corrected here.
The turning points — public web APIs that offered JSON alongside XML, then JSON only, and REST displacing SOAP for most new services
The turning points — many public web APIs exposed JSON alongside XML, and many later services chose JSON as their primary representation. Lightweight HTTP styles also became common for application APIs while SOAP remained in established ecosystems. Exact market shares, first movers and dates vary by source and cannot be established from this formatter repository.
Accordingly, unsupported historical claims are omitted or corrected rather than converted into a tidy single-cause story. The defensible mechanism is interoperability pressure: client libraries, documentation, tooling and neighboring services reinforce a format once teams standardize around it. That feedback can explain local defaults without claiming that XML vanished or that every REST API uses JSON.
The costs of the switch
The costs of the switch — JSON has no native distinction between attributes and child elements, no mixed-content model and no comment syntax. Base JSON grammar also does not define an application schema. Teams that need contracts add separate systems such as JSON Schema or OpenAPI, each with its own vocabulary, tooling and versioning decisions.
Conversion can therefore lose information unless mappings are designed explicitly. Repeated XML elements may become arrays, namespace-qualified names need a representation, and text interleaved with markup cannot always become a simple object cleanly. Simpler payload syntax moves some complexity into external contracts or conventions; it does not make validation, evolution and documentation unnecessary.
Where XML still wins
Where XML still wins — publishing workflows benefit from mixed content and established document vocabularies, while office formats package XML parts to represent rich documents. Mature finance and enterprise messaging standards may rely on namespaces, schemas, signatures or long-lived tooling investments. Replacing the syntax would require ecosystem coordination, not just a shorter sample payload.
XML is also useful when transformations and path-based queries are central to the workflow. JSON can serve these domains with additional conventions, just as XML can serve ordinary APIs, but migration value must exceed contract and tooling costs. Popularity in browser-facing services is not proof of superiority for every representation problem, and unsupported claims of total displacement are corrected or omitted.
What this does not cover
What this does not cover — binary alternatives such as Protocol Buffers and MessagePack, which compete on different terms. Their wire size, schema requirements, streaming behavior and tooling need separate evaluation. Nor does this compare hypermedia conventions, transport protocols or API styles; SOAP versus REST is not simply XML versus JSON, and either representation can travel over HTTP.
This is also not a sourced quantitative history of API adoption. Precise statements about dates, percentages, first implementations or industry-wide causes are unsupported by the listed repository evidence, so they are omitted or corrected. The article instead explains observable format capabilities and plausible engineering consequences without presenting those consequences as proof of a complete historical narrative.
Takeaway: JSON won on simplicity, not completeness
Takeaway: JSON became the common default for many web APIs through a compact data model, direct support in mainstream languages and extensive surrounding tooling, not because it contains every feature XML offers. XML remains appropriate where document structure, namespaces, transformations or established schemas are central. Format choice follows the contract and ecosystem rather than a universal ranking.
ToolAcre reflects JSON’s narrow model by parsing, validating and pretty-printing JSON on this route; it does not certify API semantics or make XML obsolete. Use cross-format conversion only when a defined mapping preserves required information. Keep the history equally careful: unsupported claims about singular turning points or complete replacement are omitted or corrected, leaving mechanisms and present behavior that can be defended.