Free online developer tools
Convert JSON objects into XML instantly in your browser. Paste JSON, transform nested data, review the converted XML, copy the result, and download the output for use in integrations, config files, legacy systems, and structured data workflows.
JSON is common in modern APIs and applications, while XML is still used in many legacy systems, integrations, feeds, document workflows, and enterprise tools. A JSON to XML converter helps bridge those formats so you can move structured data into systems that expect XML output.
This converter is designed to run directly in the browser, which means the JSON you paste and the XML it generates are handled locally on your device during the normal conversion workflow.
For more details about site usage and analytics, read our Privacy Policy.
Paste valid JSON into the input field and click Convert. The tool will generate XML output with a root wrapper and escaped values where needed. You can then copy the converted XML or download it as a file.
{
"user": {
"name": "John",
"skills": ["js", "css"]
}
}
<?xml version="1.0" encoding="UTF-8"?>
<root>
<user>
<name>John</name>
<skills>js</skills>
<skills>css</skills>
</user>
</root>
XML carries data in two places: element content and attributes, as in
<user id="42">Ada</user>. JSON has only one — keys and values —
so there is no natural home for that id="42". Every JSON-to-XML converter has
to choose a convention, and they do not agree. This tool turns every JSON key into an
element, which is unambiguous but means it never produces attributes at all. Others look
for keys prefixed with @ and emit those as attributes.
The practical consequence is that a round trip is not guaranteed. If your XML started with attributes, converted to JSON, and now converts back here, those attributes come back as child elements, not attributes. The document is still valid XML and carries the same data, but it is structurally different — which matters if a schema (XSD/DTD) or an XPath expression on the far end expects attributes in specific places.
A JSON array becomes repeated sibling elements: {"tag":["a","b"]} turns into
two <tag> elements. That reads naturally, but XML has no concept of "this
is a list", so a one-element array and a plain value produce identical markup — a single
<tag>. When something reads that XML back, it cannot tell whether
tag was a scalar or an array of length one. Consumers routinely guess wrong,
which is why XML-driven APIs so often need explicit "always treat this as a list" rules.
JSON keys are just strings — they can be empty, start with a digit, or contain spaces and
symbols. XML element names cannot. A name must start with a letter or underscore, cannot
contain spaces, cannot begin with the letters xml, and a key like
"123" or "first name" is simply not a valid tag. A converter has
to either sanitise those names — losing fidelity — or emit broken XML. If your JSON has
keys drawn from user input or from CSV headers, expect to clean them before conversion.
Values are safer but still need care: &, <, and
> in text content must be escaped to &,
<, and >, or the result is not well-formed.
XML, like CSV, has no built-in types. The JSON number 42 and boolean
true both become plain text inside a tag, and nothing in the XML records that
they were ever a number or a boolean — that meaning only comes back if a schema imposes it.
null has no standard representation at all, so converters variously emit an
empty element <x/>, an xsi:nil attribute, or nothing.
Finally, XML requires exactly one root element, while JSON's top level can be an array or a
bare value. That is why this tool wraps output in a <root> element: a
top-level array of records has no single name of its own, so one has to be supplied.
Not reliably. JSON has no attributes, so this tool emits everything as elements; if the XML later becomes JSON and returns, original attributes stay elements. Arrays are lossy too — a one-item array and a scalar produce identical XML. The data survives, but the exact structure usually does not.
As repeated sibling elements sharing the array's key name. Because XML has no list type, a reader cannot distinguish an array of one from a single value, so the receiving system often needs an explicit rule to always treat that element as a collection.
Probably a key that is not a legal XML element name. Names cannot start with a digit,
contain spaces, or begin with xml, so keys like "123" or
"first name" — common when they come from CSV headers or user input — break
the output unless they are sanitised first.
XML has no types, so a number or boolean becomes plain text with no marker of its
original type. null has no standard form — it may appear as an empty
element, an xsi:nil attribute, or be omitted entirely, depending on the
converter.
XML permits exactly one top-level element, but JSON's top level can be an array or a bare value that has no name. A single root wrapper is added so the result is well-formed XML.