JSON to XML Converter
Convert JSON to well-formed XML — for SOAP endpoints, legacy interfaces and systems that still speak angle brackets.
When JSON needs to become XML
Modern APIs speak JSON, but a large part of the enterprise world still runs on XML: SOAP services, SEPA/banking formats, RSS, SVG, Java configs, decades of B2B interfaces. When your JSON data has to enter one of those systems, this tool does the mechanical part: keys become elements, nesting becomes nesting, arrays become repeated tags, and the result is indented, well-formed XML with a proper declaration.
The mapping rules
{ "user": { "name": "Ada", "roles": ["admin", "dev"] } }
<?xml version="1.0" encoding="UTF-8"?>
<root>
<user>
<name>Ada</name>
<roles>admin</roles>
<roles>dev</roles>
</user>
</root>- Everything is wrapped in a single
<root>element — XML requires exactly one document root, JSON doesn't. - A top-level JSON array becomes repeated
<item>elements inside the root. - Special characters in values (
&,<,>) are escaped automatically.
One rule JSON doesn't have: element names
XML element names are stricter than JSON keys: no spaces, no leading digits, only letters, digits, _, - and .. If any key in your document breaks that rule, the converter refuses with the exact key named — because silently "fixing" names would corrupt a format someone else's parser depends on. Rename in the JSON (the formatter plus a search is the quick way), then convert.
Frequently asked questions
Why is everything wrapped in a <root> element?
XML requires exactly one document root; JSON has no such rule. If your target system expects a specific root tag, rename <root> after converting — or structure the JSON as {"yourRoot": {...}} and the wrapper contains exactly one meaningful child.
How are arrays represented?
As repeated elements with the same name — ["a","b"] under key roles becomes <roles>a</roles><roles>b</roles>. That is the standard XML idiom; there is no XML array type.
Can it produce XML attributes instead of child elements?
No — plain JSON has no concept of attributes, so any attribute mapping would be an arbitrary convention. Values become element content. If a schema requires attributes, that transformation is specific to the schema and belongs in an XSLT or code.
Is the output valid against my XSD/SOAP schema?
It is well-formed XML — syntax guaranteed. Schema validity (element order, namespaces, required attributes) depends on your XSD and usually needs hand-tailoring on top of this structural conversion.
What happens with null values and special characters?
null becomes an empty element, and &, <, > in values are escaped to &, <, > automatically — the sample above demonstrates it with "Fragile & urgent".