JSON to XML Converter
Because some APIs still speak angle brackets.
What this does
Paste JSON, get XML. Every key becomes an element, the whole thing lands inside a <root> element, and you get an XML declaration and two-space indentation for free. Ampersands, angle brackets and quotes in your values get escaped, so one stray & won't break the document.
Here's a small order going in:
{
"order": {
"id": 1042,
"customer": "Ada & Co",
"items": ["pen", "ink"],
"note": null,
"paid": true
}
} And here's what comes out:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<order>
<id>1042</id>
<customer>Ada & Co</customer>
<items>pen</items>
<items>ink</items>
<note/>
<paid>true</paid>
</order>
</root> Look at items. XML has no array type, so each entry repeats the tag: two <items> elements, no wrapper. The null turned into <note/>. The number and the boolean are plain text now, because XML doesn't do types. Whatever reads this file decides what 1042 means.
Common use cases
Talking to a SOAP service or an enterprise API that predates JSON. Build the payload in JSON, which is nicer to write, convert it, then drop it into the envelope the service expects.
Making test fixtures for code that only reads XML. Write the data once in JSON and generate the XML instead of typing closing tags by hand.
Checking how a JSON structure maps to XML before you write the real mapping code. Seeing the shape beats arguing about it.
Things to know
XML names are pickier than JSON keys. Anything other than letters, digits, underscores, dots and hyphens becomes an underscore, and a name that starts with a digit gets one in front. So first name turns into first_name, 2fa into _2fa, and soap:Body into soap_Body. Namespace prefixes don't survive. Accented letters get swapped too: café comes out as caf_.
A top-level array becomes <root> with one <item> per entry. An empty array or object under a key becomes an empty element like <tags/>. Nested arrays flatten, so [[1,2],[3]] under a gives three <a> siblings and the grouping is gone.
Numbers pass through JavaScript on the way. 1.0 comes out as 1, and integers past 253 lose precision: 12345678901234567890 turns into 12345678901234567000. If an ID has to survive digit for digit, make it a string in the JSON.
Privacy
The conversion runs in your browser. Order data, customer records and whatever's hiding in that config blob stay on your machine. After one visit, it works offline too.
Questions
Can I turn JSON keys into XML attributes?
No. Every key becomes a child element. Keys like @id don't get special treatment either: they're sanitized into an element named _id. If your schema needs attributes, convert first and move those values by hand.
Why is there a <root> element I didn't ask for?
XML allows exactly one top-level element, and a JSON object can have as many top-level keys as it likes. Wrapping everything in <root> keeps the output legal. Rename it after converting if your consumer expects something specific.
How do I get a wrapper element around array items?
Nest the array one level deeper. {"items": {"item": ["pen", "ink"]}} gives you an <items> element holding two <item> elements. A bare array under items repeats <items> instead.
Can I convert XML to JSON and back again?
You'll get XML back, just not your XML. Our XML to JSON tool stores attributes under an @attributes key, and this converter writes that out as an element called _attributes. The result also lands inside a fresh <root>, and number formatting is gone: 12.50 comes back as 12.5.
Is the output valid XML?
It's well-formed: one root, escaped special characters, an XML declaration. Valid is a stricter word that means it matches a schema (XSD or DTD), and the tool doesn't know yours. One gap: control characters like \u0001 in a JSON string pass straight through, and XML 1.0 doesn't allow them.