Why this comparison still matters
Most developers treat JSON vs XML as a settled question — JSON won, XML lost, move on. The reality is more interesting. JSON absolutely dominates the web APIs and configuration files you write today, but XML still runs enormous chunks of the enterprise world: SOAP services, Microsoft Office (.docx and .xlsx are XML archives inside a zip), SVG graphics, RSS and Atom feeds, Spring configuration, legal document exchange (UBL, NIEM), healthcare messaging (HL7 v3, CDA), and aviation data (FIXM). If your software touches any of those ecosystems, you don't get to choose.
This article compares the two formats honestly: syntax, verbosity, parsing, schema, and the wider ecosystem. The goal is to help you make a defensible choice when the decision is genuinely yours.
JSON: lean, typed, web-native
JSON (JavaScript Object Notation) is specified in RFC 8259 and ECMA-404. It defines exactly six data types: string, number, boolean, null, object, and array. That minimalism is the format's biggest advantage. A typical JSON document maps directly onto the data structures of nearly every modern language, so parsing is one function call: JSON.parse() in JavaScript, json.loads() in Python, encoding/json.Unmarshal in Go.
The grammar is small enough that a compliant parser fits in a few hundred lines of code, and parsing is fast — V8's JSON parser handles megabytes per millisecond. Wire size is compact: there are no closing tags, no attribute syntax, and string keys can be short. Numbers are IEEE 754 doubles, which is fine for most data but bites you on 64-bit integers. Any integer above 2^53 loses precision, which is why large platforms return identifiers like tweet IDs and Stripe object IDs as strings.
JSON's weakness is the flip side of its minimalism. There is no native date type — you pick ISO 8601 strings or epoch milliseconds and hope every consumer agrees. There are no comments, which makes hand-written configuration awkward; that gap produced JSON5, JSONC, and pushed many projects to YAML or TOML for configs. There are no namespaces, so extending a schema means inventing naming conventions. The official schema language, JSON Schema (draft 2020-12), is powerful and expressive but verbose, and it is arguably underused outside OpenAPI specifications.
Despite those gaps, JSON's simplicity has made it the default wire format for everything from REST APIs to NoSQL document stores (MongoDB's BSON is a binary superset of JSON) to message queues (AMQP, Kafka JSON payloads).
XML: verbose, structured, battle-tested
XML 1.0 was published by the W3C in 1998 and is now in its fifth edition. An XML document is a tree of elements, each with attributes, nested text, and optional child elements. Namespaces (via xmlns declarations) let you mix vocabularies without name collisions — a feature JSON still has no equivalent of. The choice between attributes and child elements is a constant design decision, which is either flexibility or ambiguity depending on your perspective.
XML's real strength is the ecosystem built around it. XSD (W3C XML Schema) provides strict type validation with cross-references, key constraints, and inheritance. XSLT transforms documents declaratively — a feature with no JSON equivalent. XPath and XQuery let you address any node in any document. SOAP, while unfashionable, still powers payment networks, ERP integrations, and government APIs. The Office Open XML format that .docx and .xlsx use is XML inside a zip — every Word document is, under the hood, a tree of XML parts. SVG, the vector graphics format the modern web depends on, is XML.
The cost is verbosity. XML's closing tags and attribute syntax typically produce documents 20–40% larger than equivalent JSON. The grammar is also more complex: a conformant parser must handle DTDs, entity expansion, namespace resolution, CDATA sections, and processing instructions. That complexity has produced real CVEs. XXE (XML External Entity) injection let attackers read arbitrary files from a server by declaring external entities in the DTD; the 'billion laughs' attack caused exponential memory growth through nested entity expansion. Modern parsers (libxml2, Xerces) disable external entity resolution by default, but the surface area remains.
Parsing models and security pitfalls
The parsing models differ in ways that matter at scale. JSON is naturally parsed into a single in-memory tree — JSON.parse in V8 produces a JavaScript object graph directly, and most language bindings do the same. For very large documents this means loading the entire structure into memory, which has produced denial-of-service patterns (deeply nested JSON can blow stack limits). Streaming JSON parsers (SAX-style, like Oboe.js or Python's ijson) exist but are not the default and are not part of any specification.
XML has two well-established parsing models. DOM parsers build the entire tree (memory-heavy but flexible); SAX and StAX parsers stream events (low memory, ideal for huge documents). For multi-gigabyte XML files — common in enterprise data exchange — streaming is mandatory, and XML's standardized streaming APIs are mature. JSON has nothing equivalent at the language-spec level, which is one reason heavy-data pipelines in finance, science, and government still use XML.
Security surfaces differ. JSON's main risk is prototype pollution in JavaScript libraries that recursively merge user input into objects — a class of bug that has produced RCE vulnerabilities in lodash, jQuery, and others. The defense is Object.create(null) or Map for untrusted input. XML's risks are more numerous and historically severe: XXE (external entity expansion reading local files or performing SSRF), the billion laughs entity-expansion DoS, and DTD-based attacks. Modern parsers disable external entities by default, but the configuration matters and the surface is larger.
Both formats need input validation. JSON Schema validators (AJV in JavaScript, jsonschema in Python) are now performant enough for production gateways and ship as middleware in FastAPI and OpenAPI toolchains. XSD validation is built into most XML parsers but is slower and more complex to author. For new work, JSON Schema plus a runtime validator is the lighter-weight path; for enterprise XML, XSD remains the standard.
Side-by-side comparison
When to choose which
Choose JSON when you are building a public web API, the data layer for a single-page application, a CLI tool's configuration file, or anything consumed primarily by JavaScript. The format's first-class mapping to JS objects, small wire footprint, and ubiquitous tooling make it the right default. If you need validation, layer JSON Schema on top — modern frameworks (OpenAPI, FastAPI, AJV, Zod) handle it cleanly. If you need a more human-friendly config format than JSON, reach for YAML or TOML rather than XML; they fill the same niche with less ceremony.
Choose XML when you are integrating with enterprise systems that already use it. SOAP services, SAML single sign-on, RSS and Atom feeds, SVG, OOXML office documents, HL7/CDA healthcare records, UBL and NIEM legal/government exchange formats, XBRL financial reports — all expect XML. Fighting the ecosystem with JSON-to-XML bridges adds fragility for no real benefit, and tools in those domains (XSLT processors, XSD validators, industry-specific XML tooling) have no JSON equivalents.
Choose XML also when you genuinely need its features: mixed content (text interleaved with markup, like prose with inline footnotes or annotations), strict schema validation with cross-document key constraints, or declarative transformations (XSLT is unmatched for converting one structured document format into another). DocBook, DITA, JATS, and similar publishing workflows rely on this combination, and JSON simply cannot represent mixed content naturally.
Avoid XML for new internal APIs where you control both ends. The verbosity and parser complexity cost you every day for capabilities you will not use, and the security surface (XXE, billion laughs) is one misconfiguration away from a CVE. Avoid JSON only when you need mixed content, schema-driven validation with constraints JSON Schema cannot express, or you are publishing into an XML-native ecosystem.
A hybrid pattern is increasingly common: JSON for your public API and internal services, XML at the boundary with legacy systems. Modern integration platforms (MuleSoft, Apache Camel, AWS API Gateway) handle the translation, but treat the XML surface as an adapter, not a core format.
Conclusion
JSON won the web, and that verdict is not changing. But 'JSON won' is not the same as 'XML is dead.' XML remains the right tool for enterprise document exchange, office file formats, vector graphics, and any domain where mixed content, namespaces, and mature schema tooling matter. Pick the format your ecosystem expects, default to JSON when the choice is genuinely yours, and resist the urge to convert legacy XML to JSON just because JSON feels more modern.