JSON to XML
Convert JSON into well-formed XML with a configurable root element. Arrays become repeated elements and special characters are escaped correctly.
Convert JSON into well-formed XML with a root element you choose. Object keys become element names, arrays become repeated elements, and characters such as <, > and & are escaped properly so the result parses in any XML tool.
Use it when an integration expects XML while your source data is JSON: a SOAP endpoint, a legacy import format, an RSS or sitemap fragment. Because XML has no native notion of an array, the repeated-element convention is what keeps lists intact when the document is parsed back.
How to convert JSON to XML
Paste your JSON
Set the root element name
Copy or download the XML
FAQ
How are arrays represented?
As repeated elements with the same name, which is the conventional way to express a list in XML and the form most parsers expect.
Are special characters escaped?
Yes, <, >, & and quotes are escaped so the document is well-formed. Keys that are not valid XML names are sanitised, with the original kept where possible.
Can I add attributes or namespaces?
Not in this tool - the output is element-based with an optional root. For attributes and schemas, post-process the result or generate the XML from your own template.
What root element does it use?
You set it; "root" is the default. Choose a meaningful name because importing systems often key on it.
Does it validate against a schema?
No. The XML is well-formed, but validating against an XSD or DTD is a separate step in your pipeline.
Is my data uploaded?
No, conversion happens in your browser.
At a glance
| Input | JSON |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.