When to Use XML in a JSON World

XML's original purpose was marking up documents, and that is still where it has no real rival. When text and structure are interleaved — a paragraph that contains bold spans, footnotes and inline links — XML expresses it naturally, because an element can hold both text and child elements at once. This is why formats like XHTML, DocBook, SVG and the Office Open XML behind .docx files are all built on XML rather than JSON, which has no concept of mixed content.

The same strength shows up in graphics and feeds. An SVG file is XML: elements nest, attributes carry geometry, and the whole thing can be embedded in HTML and styled with CSS because it is a real document tree. RSS 2.0 and Atom, defined in RFC 4287, describe publications whose item content is itself markup. Office Open XML packs a .docx as a zip archive of XML parts. None of these would be pleasant as JSON, because JSON cannot say that a run of bold text sits in the middle of a sentence without inventing an encoding for it.

XML draws a distinction JSON lacks: the difference between an element's content and its metadata, expressed as attributes. Namespaces then let documents from different vocabularies mix safely without name clashes — essential in large enterprise systems. And XML has mature, powerful schema languages in XSD and DTD that can validate structure, types and constraints far more precisely than most JSON-schema setups. Where a contract between organisations must be strict and machine-checkable, that ecosystem is a genuine advantage.

Validation is where the gap is widest. An XSD can require that an element appears between two and five times, that a value matches a pattern, that a number falls inside a range, and that an identifier used in one part of a document refers to a key defined in another. RELAX NG offers comparable power with a far more readable grammar, and Schematron adds rule-based assertions for the constraints a grammar cannot express, such as "if this attribute is present, that element is required". Reproducing all of that with hand-written checks is exactly the work these schema languages already did.

XML ships with a query language, something JSON only grew equivalents for much later. XPath addresses nodes by path, so an expression like /invoice/items/item[@currency='EUR'] selects by structure and attribute in one go, with predicates, axes such as parent and following-sibling, and functions like contains() and starts-with(). Browsers implement XPath 1.0 through document.evaluate; XPath 2.0 and 3.1 add types and sequences, and 3.1 adds maps and arrays so the same language can query JSON. One practical snag: if a document declares a namespace, an unprefixed path will not match its elements — you must bind a prefix in the evaluation context or fall back on local-name(). XSLT then uses XPath to transform one document into another.

XML's flexibility has costs you should configure away. The declaration's encoding attribute and a byte-order mark can disagree, and a BOM sitting in front of the declaration breaks strict parsers, so UTF-8 without a BOM is the safe default. Five characters — ampersand, the angle brackets, apostrophe and double quote — must be escaped in content, which is what CDATA sections exist to avoid for blocks of code or embedded markup. Most importantly, DTDs allow entity definitions, and a document that nests them can expand exponentially: the billion laughs attack turns a few kilobytes into gigabytes of memory, and external entities can read local files. Disable DTD processing and external entity resolution on any parser that touches untrusted input.

For the everyday job of shuttling plain data between a browser and a server, JSON is lighter, faster to parse and simpler to work with, and you should prefer it. The honest rule is about the shape of the problem: choose XML for documents, rich metadata and strict cross-organisation contracts; choose JSON for compact data exchange. Many teams live in both worlds and simply convert between them at the boundary, keeping XML where the schema and the tooling earn their keep.

MarkupSuite handles the XML you actually meet: it checks a document for well-formedness and points at the line that broke, pretty-prints minified feeds and API responses, runs XPath expressions against the tree so you can pull one value out of a large file, and converts the result to JSON. It all runs client-side, so a SOAP response with customer data in it never leaves the browser.