Nobody chooses XML for a new project in 2026. But legacy systems, enterprise integrations, SOAP APIs, and certain government/financial data standards still require XML. When your modern application speaks JSON and the system you are integrating with speaks XML, you need a conversion layer.
The conversion is not as straightforward as it appears. JSON and XML have different data models, and some JSON structures have no natural XML equivalent (and vice versa).
The fundamental mismatches
Arrays. JSON has first-class arrays. XML does not. A JSON array like {"colors": ["red", "green", "blue"]} must be represented in XML as repeated elements:
<colors>
<item>red</item>
<item>green</item>
<item>blue</item>
</colors>
The element name "item" is arbitrary -- XML has no concept of anonymous array elements.
Attributes vs elements. XML elements can have attributes: <person name="Alice" age="30"/>. JSON has no equivalent. During conversion, attributes are typically mapped to properties with a prefix like @ or _attr:
{"person": {"@name": "Alice", "@age": "30"}}
Data types. JSON distinguishes strings, numbers, booleans, null, objects, and arrays. XML treats everything as text. <age>30</age> is a string in XML; {"age": 30} is a number in JSON. Conversion to XML loses type information; conversion from XML must infer types or treat everything as strings.
Namespaces. XML has namespaces (xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"). JSON has no equivalent. Namespace handling in conversion is the source of most conversion library bugs.
JSON to XML conversion rules
A reasonable default mapping:
{
"person": {
"name": "Alice",
"age": 30,
"active": true,
"address": {
"city": "Portland",
"state": "OR"
},
"hobbies": ["hiking", "coding"]
}
}
Converts to:
<?xml version="1.0" encoding="UTF-8"?>
<person>
<name>Alice</name>
<age>30</age>
<active>true</active>
<address>
<city>Portland</city>
<state>OR</state>
</address>
<hobbies>
<item>hiking</item>
<item>coding</item>
</hobbies>
</person>
Handling edge cases
Null values. JSON null can be represented as an empty element (<field/>) or a self-closing element with a nil attribute (<field xsi:nil="true"/>). The choice depends on the XML schema you are targeting.
Mixed content. XML allows text mixed with elements: <p>Hello <b>world</b></p>. JSON cannot represent this directly.
Root element. XML requires a single root element. If your JSON has multiple top-level keys, you need to wrap them in a root element.
When you encounter this in practice
Payment gateways. Some payment processors still use XML-based APIs or accept XML alongside JSON.
Government integrations. Tax filing systems, healthcare data exchange (HL7), and financial reporting standards (XBRL) use XML.
RSS and Atom feeds. Feed generation from JSON data requires XML output.
SOAP services. Legacy enterprise SOAP APIs require XML request bodies with specific namespaces and envelope structures.
I built a JSON-to-XML converter at zovo.one/free-tools/json-to-xml-converter that handles the conversion with configurable array element naming, attribute mapping, and root element specification. Paste JSON, get well-formed XML. Also supports XML-to-JSON in the reverse direction.
I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.
Top comments (0)