JSON to XML Converter

What is the mismatch between the JSON and XML data models?

Converting JSON to XML is not a formatting change. The two formats describe data differently, and four gaps have to be bridged by convention rather than translation.

Each of those choices is exposed as an option here rather than being fixed, and every rewritten key is reported so you can see what the conversion changed.

How to convert

1. Paste JSON An invalid document is reported with its line and column.
2. Name the root element XML requires one. If your JSON has several top-level keys, they all become children of it.
3. Decide how arrays are handled Leave the wrapper name empty to repeat the parent key, or supply one to keep the list boundary visible.
4. Choose a null convention xsi:nil="true", an empty element, or omit the element entirely.
5. Read the mapping notes Renamed keys, empty arrays and wrapped roots are all listed.

Arrays: the gap that breaks round-tripping

XML has no array construct. The conventional equivalent is repeating an element name:

JSON:
{ "items": [ { "sku": "AB-100" }, { "sku": "CD-200" } ] }

XML:
<root>
  <items>
    <sku>AB-100</sku>
  </items>
  <items>
    <sku>CD-200</sku>
  </items>
</root>

That is idiomatic XML, and it creates a problem that no converter can solve. A one-element array produces XML identical to a plain object:

{ "items": [ { "sku": "AB-100" } ] }   and
{ "items":   { "sku": "AB-100" }   }

both produce:
<items><sku>AB-100</sku></items>

Convert that XML back to JSON and the array is gone. This is the single biggest reason JSON-to-XML-to-JSON is not reliably lossless, and it is why an API that returns one item where it usually returns several so often breaks a client.

Supplying a wrapper name avoids the ambiguity by keeping the list boundary explicit:

<items>
  <item><sku>AB-100</sku></item>
</items>

Now the container and the members are distinguishable, and a one-element list still looks like a list. If the XML will be read back as JSON, use this form.

Element names: what XML will not accept

XML element names must start with a letter or underscore, and may then contain letters, digits, hyphens, dots and underscores. No spaces, no @, no brackets, and nothing beginning with a digit. JSON keys have no such limits, so real payloads regularly need rewriting.

Every rename is listed in the mapping notes. This matters more than it looks: a renamed element will not match an XPath expression or an XSD written against the original key, so the receiving system has to agree with the convention.

Examples: nulls, types and special characters

Null

XML has no null. The three available conventions mean different things to a consumer:

xsi:nil    <middle_name xsi:nil="true"/>    explicit null, understood by XSD tooling
empty      <middle_name/>                    ambiguous: null or empty string?
omit       (element absent)                   ambiguous: null or not supplied?

xsi:nil is the only one that distinguishes null from empty, which is why it is the default here. It requires the XML Schema instance namespace, so the declaration is added to the root element automatically when any null is present.

Types

Everything in XML is character data. <total>249.99</total> and <total>abc</total> are equally valid XML; only a schema makes one wrong. The optional type attributes make the original JSON type visible:

<total type="number">249.99</total>
<paid type="boolean">true</paid>

This is a convention, not a standard. It helps a converter reading the XML back, but a strict schema will reject unexpected attributes, so only enable it if the consumer expects them.

Special characters

Three characters must be escaped in element content: & becomes &, < becomes <, and > becomes >. So the JSON string "5 < 10 & rising" is written 5 < 10 & rising.

For longer values with many special characters, a CDATA section is easier to read:

<note><![CDATA[5 < 10 & rising]]></note>

The content inside CDATA is taken literally. The one thing it cannot contain is the sequence ]]>, which is split across two sections when it occurs.

Note also that XML is markedly more verbose: every value carries an opening and closing tag, so converted output is typically 40–60% larger than the JSON.

Use cases

• Calling a SOAP service. Legacy enterprise endpoints require an XML body where the modern side of the system speaks JSON.
• Producing a file for a system that only reads XML. Older ERP, banking and government interfaces frequently do.
• Generating a feed. RSS, Atom and sitemap formats are XML; converting structured JSON gives you the skeleton.
• Building a test fixture for an XML parser. Faster than hand-writing nested elements.
• Checking how a mapping will behave. The renamed-key and array notes show where a naive conversion would have broken an XPath or a schema.
• Preparing input for an XSLT transform. XSLT operates on XML, so JSON data has to be converted first.

The reverse direction is XML to JSON, which faces the mirror-image problems around attributes and repeated elements. For flat configuration output, XML to Properties is often a better fit, and the XML Formatter and XML Validator handle tidying and checking.

Privacy

Parsing and serialising run in your browser; the JSON is not uploaded. Usage analytics record only the null convention, how many keys were renamed and a coarse size band — never the data.