JSON to XML Converter
Attribute and text conventions respected, and every value escaped correctly.
There is no canonical mapping, so agree on one
JSON and XML are not isomorphic, and no standard defines how to move between them. Every tool invents its own conventions, which means two systems can agree on the data and still fail to read each other's XML. The convention used here is the one most JSON-to-XML tools converge on, and it is worth stating explicitly so both sides can implement it.
| JSON | XML | Reason |
|---|---|---|
{"@id": "7"} | <a id="7"/> | A key starting with @ becomes an attribute |
{"#text": "hi"} | <a>hi</a> | The #text key becomes element content |
{"a": [1, 2]} | <a>1</a><a>2</a> | An array becomes repeated elements, using the key as the tag |
{"items": [1, 2]} | <item>1</item><item>2</item> | A plural key is singularised for the repeated element |
{"a": null} | <a/> | Absent value becomes an empty element |
{"a": true} | <a>true</a> | XML has no boolean type — everything is text |
What is lost in both directions
- Type information. XML is text throughout;
42,"42"and42all serialise identically and the distinction is gone. - Order within objects. JSON objects are unordered, XML elements have sequence. Converting XML to JSON and back can reorder siblings.
- Mixed content. An XML element that interleaves text and child elements —
<p>Hello <b>world</b>!</p>— has no clean JSON representation. It is the one structure that genuinely cannot round-trip. - Namespaces. XML prefixes and namespace URIs are a document-level concern with no JSON counterpart.
- Comments and processing instructions are dropped.
- CDATA sections are normalised into ordinary escaped text.
The escaping you cannot skip
Five characters must be escaped in XML content and attributes: & as &, < as <, > as >, and quotes. The ampersand must be replaced first, otherwise the entities you just generated get escaped again and render as visible source. Also note that XML has no — the named entities you may know from HTML are not available unless a DTD declares them, so use numeric character references.
Verbosity, and why it matters at scale
For the same data, XML typically runs two to three times the size of JSON, because every value needs an opening and a closing tag. That overhead matters for mobile payloads and for log storage. XML retains real advantages — document validation against a schema, mature tooling for documents rather than data, and a long history in enterprise and publishing systems — but for new APIs carrying records, JSON is the smaller and simpler choice.
How to use it
- Paste JSON.
- Set the root element name —
rootby default. - Convert and check attribute placement.
- Validate against the XML schema the receiving system expects.
Worth knowing
- Keys beginning with
@become attributes;#textbecomes element content. - Arrays become repeated elements; plural keys are singularised for the tag name.
- XML has no native boolean or number type — everything is character data.
- XML has no named entities without a DTD, so use numeric references.
Limitations
- Mixed content — text interleaved with child elements — cannot be represented.
- Namespace prefixes and URIs are not generated.
- Comments and processing instructions in the source JSON do not exist to preserve.
- All type distinctions are lost; numbers and strings become indistinguishable text.
Frequently asked questions
How do I represent XML attributes in JSON?
@, so <a id="7"/> becomes {"@id": "7"}. This tool reads and writes that convention in both directions.Why did my numbers become strings?
true or false.Can mixed content round-trip?
<p>Hello <b>world</b>!</p> interleaves text and elements in a way JSON cannot express. Document-oriented XML should stay XML.