JSON ⇄ XML
Convert a JSON object into structurally equivalent XML
JSON to XML: How Structures Map, and What Information Is Lost
Where the two data models diverge
JSON has three things XML lacks: arrays (an ordered, same-type collection), explicit types (a number is a number and a boolean is a boolean), and no distinction between attributes and text (only key-value pairs).
XML has two things JSON lacks: attributes (metadata attached to an element) and mixed content (an element carrying both child elements and text).
That means the conversion cannot be fully lossless. Every conversion in either direction involves trade-offs, and there is no single standard for those trade-offs — which is exactly why the same JSON converted by different tools yields different XML.
Common mapping rules
| JSON | XML | Note |
|---|---|---|
| top-level object | one root element | XML allows only one root, so a root name must be supplied |
| object | one element, each key becomes a child | key name is used directly as the tag name |
| array | repeated child elements with the same name | the most common one-to-many mapping |
| string / number | the text content of an element | type information is lost; everything becomes text |
| boolean | text true/false | may be agreed as 1/0 or yes/no |
null | empty element or the element omitted | both are common; must be agreed with the receiver |
What is lost or becomes ambiguous
- The number type disappears. In JSON,
18and"18"are different values, but both become<age>18</age>in XML. When parsed back, the type to restore is purely a matter of convention. - An array and a one-element array cannot be told apart.
{"item":[1]}and{"item":1}produce exactly the same XML. When parsed back, the receiver cannot decide whether to restore an array or a single value — the classic JSON-to-XML pitfall, usually resolved by a prior agreement that "this field is always an array". - Key names may be illegal. XML tag names have character restrictions (they cannot start with a digit, cannot contain spaces, and so on). When a key violates these, you either rename it or fall back to putting the key name into an attribute.
- Attributes are not generated automatically. JSON has no "attribute" concept, so a converter generally writes everything as child elements. If the receiver's XSD requires certain values to be attributes, the output will fail validation outright.
- Namespaces. XML namespaces have no counterpart in JSON and are usually dropped.
How to use this tool
- Paste the JSON into the left input box.
- Type a root element name in the root-name field (default
root) — if the target system requires a specific root name you must change it, or the other side cannot parse. - Click convert; the output appears on the right.
The output XML-escapes text content (handling &, <, >), so content containing those characters will not break the structure. If this is for a production system, validate the result against the target system's XSD or a real sample — the trade-off points above (array shape, null representation, type restoration) have no standard answer and can only be aligned with the other end.
FAQ
How are XML attributes represented?
This tool generates JSON keys uniformly as child elements, without distinguishing attributes. If you must use attributes, process them another way first.
Why does the array have no index?
XML expresses lists through repeated tags and has no index concept. On restore, consecutive sibling elements with the same name are treated as an array.