JSON won the API wars years ago, but XML never actually left. It still runs SOAP services, enterprise configurations, RSS feeds, Office documents, and countless legacy integrations that are not going anywhere. Sooner or later, most developers face the same chore: data arrives as JSON and needs to leave as XML, or the reverse. Understanding how the two formats map to each other — and where the mapping breaks — saves hours of debugging. When you need the conversion done now, our free JSON to XML converter handles it instantly in the browser.
This guide covers how JSON and XML differ structurally, the situations where conversion is actually necessary, the mapping rules that turn objects into elements and arrays into repeated nodes, and the pitfalls that catch people out: attributes, namespaces, and the mixed-content problem.
Both formats describe hierarchical data, but they think about it differently:
The same data in both formats:
// JSON
{
"book": {
"title": "Dune",
"author": "Frank Herbert",
"year": 1965,
"tags": ["sci-fi", "classic"]
}
}<!-- XML -->
<book>
<title>Dune</title>
<author>Frank Herbert</author>
<year>1965</year>
<tags>sci-fi</tags>
<tags>classic</tags>
</book>Notice what happened to the array: JSON's ["sci-fi", "classic"] became two repeated <tags> elements, because XML has no native array type. That single difference drives most conversion complexity.
You do not convert formats for fun. The real-world triggers:
pom.xml), Android layouts, and SVG-adjacent pipelines expect XML. Build scripts often generate them from JSON sources.A reliable converter follows predictable rules. Knowing them lets you predict the output and design JSON that converts cleanly:
{"name": "Ada"} → <name>Ada</name>.true becomes <active>true</active>. Some converters use 1/0; check your tool's convention.{"middle": null} typically becomes <middle/>. Some schemas prefer the element omitted entirely — confirm what your consumer expects.Here is where naive conversion breaks down. JSON has no concept of attributes, so a converter must decide: does {"id": 7} become <id>7</id> (element) or <item id="7"/> (attribute)?
Common conventions:
@ or - become attributes: {"@id": 7} → <item id="7"/>. This is the most widely used approach.#text convention. When an element needs both attributes and text content, the text goes in a special key: {"@lang": "en", "#text": "Hello"} → <greeting lang="en">Hello</greeting>.If your target system validates against a schema, find out its attribute rules before converting. A converter's default guess is right maybe 80% of the time, and the remaining 20% fails validation in confusing ways.
{"a": 1, "b": 2} needs a wrapper: <root><a>1</a><b>2</b></root>. Converters add one automatically — make sure its name matches what the consumer expects.<soap:Envelope>). Plain JSON-to-XML output has none, so SOAP envelopes and similar structures need post-processing or a namespace-aware converter.<, >, and & in JSON strings must be escaped as <, >, & in XML. Good converters do this automatically; hand-rolled string concatenation does not.<p>Hello <b>world</b></p> (text mixed with elements) has no natural JSON equivalent. If your data includes rich text, conversion gets lossy — consider whether the rich text should travel as an escaped string instead.<first> before <last>, your converter must preserve insertion order.1965, the boolean true, and null all arrive as strings. The consumer's schema or parsing code must restore the types.XML-to-JSON has its own quirks. Repeated elements collapse into arrays (good), but a single <tags> element becomes a plain string while two become an array — an inconsistency that breaks strongly-typed consumers. This is the classic "array of one" problem. Robust converters offer an option to always create arrays for specified elements. Attributes need the reverse of the prefix convention, and namespaces either get stripped or prefixed into key names.
If you control both ends, the cleanest approach is to define the mapping explicitly rather than relying on any converter's defaults. Conventions beat cleverness in format translation.
JSON-to-XML conversion is straightforward for simple data and fiddly at the edges — attributes, namespaces, mixed content, and type fidelity are where the dragons live. For one-off conversions and quick checks, an automated tool is the fastest path: paste your JSON into our JSON to XML converter and inspect the output before wiring it into a pipeline. For production integrations, pin down the attribute conventions and schema requirements first, then automate with a library in your stack.
Arrays become repeated sibling elements with the same tag name. {"tags": ["a", "b"]} becomes <tags>a</tags><tags>b</tags>, because XML has no native array type.
By convention, most converters use a prefix: keys starting with @ (or -) become attributes. {"@id": 7} converts to <item id="7"/>. Text content alongside attributes typically uses a #text key.
The usual suspects: wrong root element name, attributes emitted as elements (or vice versa), missing namespaces, element order violations, or unescaped special characters. Validate early against the actual XSD rather than eyeballing the output.
JSON, for almost all new APIs — it is more compact, maps directly to language data structures, and is easier to read. XML remains the right choice where schemas, namespaces, document validation, or legacy system compatibility are required.
