JSON to XML

How it works

Paste your JSON into the left box; the XML appears in the right box as you type. XML permits exactly one top-level element, so the whole document is wrapped in the root name you type: 'root' works for a quick look, but naming it 'order' or 'products' usually makes the output usable as it stands. Object keys become element names and arrays become repeated elements named either 'item' or the singular of the field that contains them. XML element names cannot start with a digit and cannot contain spaces or brackets, so a key like '2024 order' is not silently mangled — it becomes '_2024_order', and the status line tells you how many keys were adapted and what each one turned into. Text is escaped for the five characters & < > " ', a null value becomes an empty element (<x/>) while an empty string stays <x></x>, because those two are not the same thing. If the JSON does not parse, you are told the line and column where it broke instead of an engine error. Copy the result with one click or download it as an .xml file.

This tool is also known as json to xml, convert json to xml, json to xml converter, json to xml online, build xml from json.

What is XML element name?

An element name is the word between the angle brackets that labels a piece of data: in <price>, the name is 'price'. The rules are narrow and non-negotiable. A name starts with a letter or an underscore, contains no spaces, cannot begin with a digit and cannot carry brackets, slashes or percent signs. Digits, hyphens and dots are fine later in the name, so 'price-2024' is legal while '2024-price' is not. Letters from any alphabet are allowed, which is why accented names pass untouched. This is the single rule that forces a converter to rewrite JSON keys: spreadsheet-style headings full of spaces and units simply cannot be element names.

What is Root element?

The root element is the single outermost element of an XML document; everything else lives inside it. The one-root rule sounds academic but has daily consequences: you cannot concatenate two XML fragments into one file, and you cannot save a bare list as a document — something has to wrap them. JSON imposes no such rule, which is precisely why a converter must add one. The name matters more than it looks, because import routines usually search for the root by name: an invoice exchange expects <invoice>, a product feed expects <products>, and a file called <root> will often be rejected before its contents are even read.

Where does the JSON versus XML difference actually show up here?

It shows up in exactly three decisions. The first is the root: JSON can start anywhere, XML insists on one top element, which is why the page asks you to name it. The second is lists: JSON marks them with brackets, XML expresses them as repeated sibling elements, so somebody has to choose what those siblings are called — and that choice decides whether the file reads well to a human or loops well in code. The third is types: JSON separates numbers, strings and booleans, while XML treats everything as text and leaves typing to an external schema, so the difference between 1024 and "1024" is lost in this direction. What XML gives back is the formal apparatus JSON lacks: attributes, namespaces and schema validation. That is why public-sector and enterprise integrations still ask for XML while web APIs moved to JSON.

Why the tool asks you for a root name

JSON may begin with an object or an array, and either is a complete document. XML has no such freedom: every document holds exactly one outermost element, and a second one at the top level makes the file invalid. That is why your data is always wrapped, and why the wrapper's name is your decision rather than a fixed default.

Pick the name the receiving side expects. If an import routine looks for <invoices>, name it invoices. Whatever you type is put through the same name rules as the keys, so 'order list' comes out as 'order_list' — spaces do not exist in element names.

The array trap: XML has no list type

In JSON, square brackets announce a list on their own. XML has no such marker; a list is expressed by sibling elements that share a name. So the conversion has to answer a question JSON never asks: what are those siblings called?

Both conventions are common. A fixed 'item' name is uniform and easy to loop over in code; the singular of the containing field reads better for a human ('items' holding 'item', 'invoices' holding 'invoice'). When no singular can be derived — 'data', for instance — the tool falls back to 'item', because <data><data> misleads whoever reads the file.

There is a consequence worth planning for: convert a single-entry array to XML, read it back, and you get one object rather than a list. Nothing in an XML document says 'this is always a list' — only a schema (XSD) does, and none is generated here. Code that consumes the output should handle the one-entry case explicitly.

Invalid keys are repaired, never silently broken

XML element names follow strict rules, and JSON keys frequently break them. The tool repairs the name, then reports how many were repaired and what each became, so nothing surprises you when you read the file later.

• Name starting with a digit → underscore in front: '2024' becomes '_2024' (dropping the digit would lose data)
• Spaces, brackets, slashes and other disallowed marks → underscore: 'price (USD)' becomes 'price__USD_'
• A colon also becomes an underscore, so the output never points at a namespace prefix that was never declared
• Names beginning with 'xml' are reserved by the standard → an underscore is prefixed
• An empty key ('') is named 'field'; an empty root name falls back to 'root'
• Accented and non-English letters are kept: 'prénom' is a perfectly valid element name and is left alone

What this tool does not generate

The conversion maps the JSON data model onto elements. XML structures that have no JSON counterpart are not invented for you:

• No attributes: every key becomes an element, so output like <item sku="UK-11"> has to be edited in by hand
• No namespace declarations; if your target format needs xmlns, add it to the root element yourself
• No schema or DTD: the output is well-formed XML, but whether it is valid against a given schema is a separate question
• Numbers and booleans are written as text, because XML carries no type information — only a schema distinguishes true from "true"
• Control characters that XML forbids outright are dropped, and the count is shown in the status line

Frequently asked questions

Why are some of my JSON keys renamed?

An XML element name cannot begin with a digit and cannot contain spaces or most punctuation. Writing such a key unchanged would produce a file no parser can read. The tool repairs the name and lists every change in the status line, so no rename happens quietly.

Can it produce attributes instead of elements?

No — every key becomes an element. JSON has no concept of attributes, so nothing in your data says which fields should become one; only the target schema knows that. If attributes are required, download the output and edit those lines.

Why does a one-entry array come back as a single object?

In XML a lone element and a one-entry list look identical; only a schema (XSD) tells them apart, and no schema is produced here. If a field must always be a list, check for the single-entry case in the code that reads the XML.

Is my JSON uploaded anywhere?

No. Parsing and XML generation happen entirely inside your browser, so customer records, order dumps or API responses stay on your machine. Nothing is uploaded, logged or stored.