JSON to XML: When You Still Need XML and How the Mapping Works
By the Super Simple Digital Tools Team · Updated June 2026
JSON won the web. It is lighter, easier to read, and native to JavaScript, so almost every modern REST API speaks it by default. Yet XML never went away, and a working developer still bumps into it constantly. SOAP web services are built on XML envelopes, and large swaths of finance, healthcare, telecom, and government infrastructure run on SOAP. RSS and Atom feeds, podcast feeds, and XML sitemaps are XML by specification, an RSS document must conform to the XML 1.0 standard. Build tools like Maven, configuration for Spring and many Java frameworks, and the Office Open XML behind .docx and .xlsx files are all XML too. If your data starts as JSON but has to travel into one of these systems, you need a clean conversion rather than a rewrite.
Conceptually the two formats agree: both describe a hierarchical tree of named values. The differences are in syntax and in a handful of features each format has that the other lacks. JSON gives you typed values, strings, numbers, booleans, null, plus arrays and objects. XML gives you elements, attributes, namespaces, comments, and processing instructions, but it treats every value as text. A faithful converter has to bridge that gap, and most of the friction in JSON to XML comes from the things XML has that JSON does not, attributes and namespaces, and the things JSON has that XML does not, real arrays and real data types.
The core mapping is simple to picture. The whole document gets a single root element, because XML allows exactly one root while JSON can start with an object or an array. Each object key becomes an element name and its value becomes the element body. Nested objects become nested elements, so {"order":{"id":5}} turns into an order element containing an id element. Arrays expand into repeated sibling elements with the same tag, the only sensible way to express a list in XML. Scalar values are written as the text content of their element, and because the type information is gone, a consumer reading the XML back has to know from context or from a schema that a given field is a number rather than a string.
A few details trip people up. XML reserves &, <, and > for its own markup, so any of those characters appearing inside a JSON value must be escaped to &, <, and > or the output will not parse. Element names are also constrained: they cannot begin with a digit and cannot contain spaces or most punctuation, so a JSON key like "2024-total" or "line items" has to be sanitised, commonly by prefixing an underscore for leading digits and replacing spaces with underscores. Empty objects, deeply nested arrays, and keys that differ only by case are other corners worth checking. Because of all this, JSON and XML are not a perfect round trip, converting JSON to XML and back can subtly change types or names.
The safe workflow is to convert, then verify. Generate the XML, eyeball the structure, and if you have a target schema, validate the output against the XSD or DTD that the receiving system publishes. If the target expects certain values as attributes rather than child elements, restructure your JSON first using an attribute convention the converter understands, rather than hand-editing the XML afterward. For SOAP, wrap the converted body in the correct envelope and namespaces the service requires. Treat the converter as a fast first draft of the document shape, and let your schema, not your eyes, be the final judge of correctness.
- Wrap your JSON in a single top-level object before converting; XML needs exactly one root element, so a bare top-level array will be wrapped automatically and the tag name may not be what you expect.
- Remember that arrays become repeated sibling elements, not a wrapper plus children, so use a singular, descriptive key name for array items to keep the XML readable.
- If the receiving schema requires data types, add type attributes (for example type="number") yourself, because XML loses JSON's number, boolean, and null distinctions in plain conversion.
- Rename any JSON keys that start with a digit or contain spaces before converting, so the element names are predictable instead of being silently underscored by the sanitiser.