Comparison
JSON vs XML: When to Use Each Data Format in 2026
For new HTTP APIs and web-first payloads in 2026, JSON is the sensible default. It's lighter on the wire, natively deserializes into every mainstream language, and every modern tooling chain — from Postman to Kubernetes — was built around it.
But “JSON won” oversells the story. Financial, healthcare, and government integrations still run on XML. SOAP webservices, ATOM/RSS feeds, DocBook, XHTML, and Office / iWork document formats are all XML-native. Understanding when each format is the right tool — and where their capabilities genuinely differ — is a core data-modeling skill.
TL;DR
| JSON | XML | |
|---|---|---|
| Standard | RFC 8259 (2017) | W3C XML 1.0 / 1.1 |
| Verbosity | Compact (no closing tags) | Verbose (open/close tags, attributes) |
| Data types | string, number, boolean, null, object, array | Everything is text — types are conventions |
| Attributes vs. elements | N/A — only key-value objects | Both, semantically distinct |
| Comments | Not allowed (JSONC / JSON5 extends) | Yes — <!-- --> |
| Schema | JSON Schema (Draft 2020-12) | XSD (mature, verbose), DTD (legacy) |
| Query language | JSONPath, jq | XPath, XQuery |
| Transform language | jq, JMESPath | XSLT |
| Namespaces | None (JSON-LD @context adds them) | First-class (xmlns) |
| Mixed content | Awkward (#text convention) | First-class |
| Binary payloads | Base64 in strings | Base64 in text, or xs:base64Binary |
| Typical use in 2026 | REST APIs, config, NoSQL | SOAP, RSS/Atom, Office docs, legacy enterprise |
The options in depth
JSON
Compact, JS-native, and the default of the modern web.
JSON encodes exactly six primitive kinds of value (string, number, boolean, null, object, array) and nothing else. That constraint is the source of both its speed — parsers are small and fast — and its weaknesses. There are no comments, no attributes vs. elements distinction, no namespaces, no mixed content, and no dates (they're always strings you interpret).
What JSON does have going for it is universality: JSON.parse is built into every browser, every language has a first-class library, and modern databases (Postgres, MongoDB, DynamoDB) can index and query it natively. For any new REST or GraphQL API, choosing anything else in 2026 requires a specific reason.
Good for
- ·REST / HTTP JSON APIs, GraphQL
- ·Configuration files (package.json, tsconfig.json, .eslintrc)
- ·NoSQL document stores (MongoDB, DynamoDB, Firestore)
- ·Structured logs (JSON logs are trivial to grep, jq, and ship to Elasticsearch)
- ·LLM structured output — the entire OpenAI / Anthropic tool-calling ecosystem is JSON
Avoid when
- ·You need mixed content (rich text mixed with structural markup) — XML is native at this
- ·You must interop with SOAP, RSS, Atom, or XML-based government/finance schemas
- ·You need XSLT-level transformation on the document itself (rare, but powerful when needed)
XML
Structured markup with attributes, namespaces, and mature transformation tooling.
XML is a full markup language: elements, attributes, mixed content, namespaces, and processing instructions. That expressiveness is why it's still the substrate for document formats (OOXML, ODF, EPUB, DocBook), publishing pipelines, and enterprise integrations where the schema needs to enforce structural rules JSON cannot express.
XML's tooling ecosystem is also, in some ways, still ahead: XSD provides much richer schema constraints than JSON Schema, and XSLT lets you declaratively transform one XML document into another (or into HTML) with no imperative code. For document pipelines, that combination is genuinely productive.
Good for
- ·SOAP web services (legacy enterprise, banking, telecom, government)
- ·RSS / Atom / RDF feeds (the entire web-syndication ecosystem)
- ·Office document formats (docx, xlsx, pptx are all zipped XML), EPUB, DocBook
- ·Configuration for systems built pre-2010 (Maven pom.xml, log4j, web.xml)
- ·Pipelines that need XSLT transformation, or schemas with cross-field constraints XSD can express
Avoid when
- ·You're building a new browser-first API in 2026 — JSON is 3-5× less code to consume from JS
- ·The payload is small and you care about wire bytes (XML overhead is 20-50% for typical structures)
- ·Your team has no XML expertise — the tooling maturity is a trap if you don't know how to use it
Which one should you pick?
→ Building a new REST API in 2026?
Use JSON unless a specific consumer forces otherwise. JS clients don't need a parser; every language has first-class libraries.
→ Integrating with SOAP or a government/finance XML schema?
Use XML — it's the schema-of-record. Convert to JSON at the edge of your service if downstream code is JSON-native.
→ Payload has mixed content (rich text with inline structure)?
XML is better. JSON forces awkward workarounds like {"type":"text","value":"…"} arrays.
→ Storing the payload in a NoSQL database with ad-hoc queries?
JSON. Postgres / MongoDB / DynamoDB all index and query JSON natively; XML is a second-class citizen.
→ The document IS the artifact (docx, EPUB, DocBook)?
XML. These formats exist because JSON cannot represent them cleanly.
Common pitfalls
- ⚠JSON has no comments. Adding them makes the file JSONC / JSON5, which most parsers reject — don't assume your parser accepts them.
- ⚠XML entity expansion (&ent;) is exploited by the “billion laughs” DoS attack. Any XML parser accepting untrusted input MUST disable DTD processing.
- ⚠“XML is more strongly typed than JSON” is a common myth — both are just text on the wire. Types are enforced by XSD / JSON Schema, not by the format itself.
- ⚠Converting XML to JSON is lossy: attributes vs. elements, mixed content, and namespaces all get squashed. Round-tripping XML → JSON → XML rarely produces byte-identical output.
- ⚠JSON numbers have no defined precision. Producing 64-bit integers or high-precision decimals can silently corrupt data at the JS parser (Number.MAX_SAFE_INTEGER = 2^53−1). Serialize as strings when precision matters.
Frequently Asked Questions
Is JSON always smaller than XML?
For structured records, yes — typically 30-50% smaller uncompressed. After gzip, the gap narrows dramatically because both formats have highly repetitive structures. If bytes matter, benchmark with your actual payloads.
Can XML represent everything JSON can?
Yes, but with more verbosity and some awkwardness around number types (everything is a string in XML unless a schema is enforced). The reverse is not true: JSON cannot cleanly represent mixed content or attributes.
Is JSON Schema as powerful as XSD?
JSON Schema (Draft 2020-12) has closed most of the historical gap, but XSD still edges ahead on cross-field constraints, complex type inheritance, and identity constraints. For most REST APIs, JSON Schema is more than sufficient.
Should I return JSON with an XML fallback via Accept header?
It sounds nice; in practice, no one uses the XML side. Skip the maintenance burden unless a specific enterprise consumer requires it.
What about YAML vs JSON?
YAML is a JSON superset optimized for human-written config files. It's not intended for machine-to-machine wire protocols — use JSON there and reserve YAML for CI configs, Kubernetes manifests, and similar.