XML vs JSON: When to use which
XML and JSON both represent structured data as text, and both are supported by every major language. JSON has become the default for web APIs because it maps directly onto the objects and arrays of programming languages. XML is older and more expressive. It remains the better choice for documents, formats that rely on schemas and namespaces, and many enterprise systems. This guide compares them side by side.
The same data in both formats
XML:
xml<user id="42"> <name>Asha</name> <roles> <role>admin</role> <role>editor</role> </roles> <active>true</active> </user>
JSON:
json{ "id": 42, "name": "Asha", "roles": ["admin", "editor"], "active": true }
The JSON version is shorter and its types are explicit: 42 is a number and true is a boolean. In XML, everything is text until a schema or your code says otherwise.
Side-by-side comparison
| XML | JSON | |
|---|---|---|
| Data types | Text only (types come from a schema) | String, number, boolean, null, object, array |
| Arrays | Repeated elements; no native list type | Native arrays |
| Attributes | Yes (<user id="42">) | No; everything is a key |
| Comments | Yes (<!-- -->) | No |
| Namespaces | Yes | No |
| Mixed content (text with inline markup) | Yes | Awkward |
| Schema languages | XSD, DTD, RELAX NG | JSON Schema |
| Query languages | XPath, XQuery, XSLT for transforms | JSONPath, jq |
| Size | Larger (closing tags repeat names) | Smaller |
| Browser parsing | DOMParser | JSON.parse (faster, simpler) |
Where XML is the better fit
- Documents rather than records. Text with inline structure, such as
<p>Click <b>Save</b> to continue</p>, is natural in XML and clumsy in JSON. That's why DOCX, XHTML, SVG and DocBook are XML. - Strict contracts. XSD schemas are mature and widely used in banking, healthcare (HL7 CDA), government and B2B integrations.
- Combining vocabularies. Namespaces let one document mix several standards safely.
- Existing ecosystems. SOAP services, RSS and Atom feeds, Maven POMs, Android resources and XML sitemaps all expect XML.
Where JSON is the better fit
- Web and mobile APIs, where the data maps directly to objects in JavaScript, Python, Swift or Kotlin.
- Configuration and data exchange between services, where compact size and fast parsing matter.
- Data with real types, where you want numbers and booleans without a schema.
- Logs and streaming, using NDJSON.
Converting between them
Converting is common but rarely lossless, because the two models differ:
- Attributes vs elements.
<user id="42">must become a key. Converters use conventions such as"@id": "42"or"_attributes": {"id": "42"}. - Single item vs array. One
<role>element usually becomes a string, while two become an array. Clients then have to handle both shapes. Force arrays for elements that can repeat. - Types. Everything from XML arrives as a string (
"42","true") unless you convert types explicitly. - Lost information. Comments, processing instructions, namespaces and the order of mixed content usually don't survive.
The XML Formatter has an Export JSON button that converts XML to JSON so you can inspect the result. Check the attributes, single-element arrays and types before you rely on the converted shape in code.
Choosing for a new project
If you're building a new API and nobody downstream requires XML, choose JSON. If you're exchanging documents, need namespaces, or are integrating with a system or standard that defines an XML format, use XML and validate it against the published schema. See How to format and validate XML and JSON vs YAML for related comparisons.