JSON ↔ XML Converter

JSON construct → XML representation: the full mapping

Because the two formats have different type systems, a converter has to make a decision for every JSON construct. This table shows the rule this tool applies (and the convention used by fast-xml-parser, which most JavaScript converters share). Read the "Caveat" column carefully — that is where round-trips break.

Attributes vs elements: the decision JSON can't make for you

In XML, the same information can be modeled two different ways, and the data itself is identical. These two are equivalent in meaning:

<!-- As an attribute -->
<book id="42">Dune</book>

<!-- As a child element -->
<book>
  <id>42</id>
  <title>Dune</title>
</book>

JSON has no concept of an attribute — it only has keys and values. So a converter needs a naming convention to distinguish the two when going both directions. This tool uses the @_ prefix (the fast-xml-parser default) when building XML, and on the way in it also accepts @, -, and $ as attribute markers. When parsing XML to JSON, attributes are stripped of their prefix entirely, so id="42" becomes a plain "id" key — which means you cannot tell, from the JSON alone, whether id was an attribute or a child element.

Why arrays are the hardest part of JSON-to-XML

XML has no array type. A JSON array is represented as repeated sibling elements with the same tag name. That works going out, but it creates a real ambiguity coming back — because XML can't tell a one-item list from a single object.

JSON in:   { "skills": ["React", "Flutter"] }

XML out:   <skills>React</skills>
           <skills>Flutter</skills>

XML in:    <skills>React</skills>      (only one!)

JSON back: { "skills": "React" }        ← now a string, not an array

This is the "single-element array" problem and it is not a bug in any one tool — it is fundamental to the formats. A parser has no way to know whether a lone <skills> element is a scalar or a one-item list, so it defaults to a scalar. Two ways teams work around it:

• A wrapper element. Model the array as <skills><item>React</item></skills> so the container is explicit. JSON-friendly, but verbose XML.
• An XML Schema (XSD). If the parser knows from a schema that skills is maxOccurs="unbounded", it always produces an array. This tool does not consume an XSD, so it can't do this.

If your reverse conversion keeps collapsing single-item arrays, that is expected behavior — add a second element or post-process the result in code to force the field into an array.

What you lose in an XML → JSON → XML round-trip

Converting one way and back is not guaranteed to give you the original document. XML carries metadata that JSON has no place to store. Here is exactly what survives and what disappears with this converter's default settings.

Bottom line: treat conversion as a one-way data transform, not a faithful document copy. If you need a byte-identical XML document back, keep the original — don't reconstruct it from JSON.

JSON ↔ XML conversion: questions people actually ask