JSON to XML converter

What does converting JSON to XML involve?

JSON and XML can both describe the same data, but they do not have the same joints. JSON has objects and arrays; XML has elements that can repeat, attributes that hang off a tag, and text that can sit inside an element alongside its children. Going from JSON to XML therefore means deciding which JSON key becomes a tag, which becomes an attribute, and what to do with an array — none of which JSON itself marks.

There is no standard for that decision. W3C never defined a JSON encoding of XML, so every tool adopts a convention and the conventions disagree. This converter uses the most widely shared one, the same as Newtonsoft's Json.NET, xml2js and Spark: a key beginning with @ becomes an attribute, a key called #text becomes the element's own text, and every other key becomes a child element. BadgerFish uses $ for text instead, and the Parker convention drops attributes altogether.

Because the mapping is a choice rather than a rule, this page names the convention it uses and warns you, for your specific document, about anything that will not come back the same way if you convert in the other direction.

How to convert JSON to XML

1. Paste your JSON into the left pane. The XML appears on the right as you type, with no button to press. Load a sample fills the pane with a small catalogue showing attributes, a repeated element and an array.
2. Set the output format. Choose one line or an indent of two or four spaces, and decide whether to include the XML declaration at the top. Both only affect the text you get, never the structure.
3. Read the warnings, then copy. Below the panes, the tool lists anything about your data's shape that the conversion cannot carry back, and how many times it occurs. If it says nothing was lost, your document is inside the convention. Copy result puts the XML on your clipboard.

What the convention needs from your JSON

XML allows exactly one root element, so the JSON has to be an object with a single key to name it. An array at the top level, or an object with two keys, has no faithful spelling as a document, and the tool says so rather than inventing a wrapper tag you did not ask for.

Below the root, keys beginning with @ become attributes and a #text key becomes the element's own text. That is what lets an element carry both an attribute and content: an object with @id and #text produces a tag with an id attribute wrapped around a piece of text, which is exactly what you would have written by hand.

An array becomes the same tag repeated once per item, because that is how XML expresses a list — there is no bracket. That rule reads naturally in the output and is also the source of the main limitation below, since XML has no way to mark that a repeat was ever meant to be a list.

What will not survive the trip back, honestly

Converting JSON to XML and back was measured over about 1,700 generated documents: 72.8% came back byte for byte identical. Every single failure had one of exactly two causes, and after accounting for those the unexplained residue was zero — so the limits below are precisely these and nothing else.

The first is an array of one item. It is written as a single tag, and a single tag reads back as a plain value, because nothing in the XML says a list was intended. An array of two or more items comes back fine; the hole is specifically the array of one. The tool flags it when it sees one.

The second is an array nested inside another array. Repeating a tag can express one level of list and no more, so the inner arrays flatten into the outer one. This is also flagged.

Two things about names are worth knowing. A JSON key can be any string, but an XML tag name cannot: a key with a space in it, or one starting with a digit, is not a legal tag. Rather than emit malformed XML, the converter renames such keys — first name becomes first_name — and reports that it did, because the key itself has changed. Separately, a key containing a colon is written as a namespace-qualified name. That is well-formed XML, but it is only valid under the XML Namespaces spec if the matching xmlns declaration is present in your JSON too, which is worth checking if you are hand-writing prefixes rather than round-tripping a document that already had them.

Why is it free?

The conversion is a parse and a re-serialise, and both happen in your browser as you type. Nothing is uploaded, so there is no server cost to recover and no reason to ask for an account before you can convert your own data.

That also means no watermark on the output, no size limit imposed to push an upgrade, and no cap on how many documents you run through it.