Skip to content
ToolBoxGeniehome

JSON to XML Converter

Developer Tools · Added

JSON and XML do not describe the same things — XML has attributes, ordered mixed content and exactly one root, JSON has arrays and unordered keys — so every converter has to pick a convention, and one that does not say which is producing output you cannot rely on. This uses the attribute-prefix form, states it plainly, and inverts the same rules going back the other way so a document survives the round trip.

Direction

Keys starting with "@" become attributes; "#text" becomes the element text.

Used when the JSON does not already have a single top-level key.

How to use the json to xml converter

  1. 1Pick the direction: JSON to XML, or XML to JSON.
  2. 2Paste your document, or load the example to see how the convention maps.
  3. 3Going to XML, set the root element name — it is used only when the JSON does not already have a single top-level key.
  4. 4Coming back to JSON, decide whether numeric-looking text should become numbers. It is off by default, because a leading zero is significant in a part number.

Examples

Attributes and children together

Input
{ "order": { "@id": "A-1042", "customer": "Meera Nair" } }
Result
<order id="A-1042"><customer>Meera Nair</customer></order>

A key beginning with "@" becomes an attribute on the element that contains it.

An array becomes repeated elements

Input
{ "list": { "item": ["one", "two"] } }
Result
<list><item>one</item><item>two</item></list>

XML has no concept of a list, so repetition is the only way to express one.

Reading XML back

Input
<book isbn="978-0131103627"><year>1978</year></book>
Result
{ "book": { "@isbn": "978-0131103627", "year": "1978" } }

The year stays a string unless type coercion is switched on, because XML never says which it was.

About the json to xml converter

The mapping, in full

An object key becomes an element name. A key starting with @ becomes an attribute of the enclosing element. The key #text becomes the element's text content, which is how an element that has both attributes and text is expressed. An array repeats the parent's element name once per item. Null becomes an empty element. Going the other way, each of those rules is inverted, and a repeated element name collapses into an array.

That last rule has a consequence worth planning for. Whether a key comes back as an array depends on how many elements happened to be present, so a list with one item in it reads back as a single object rather than an array of one. Anything consuming the JSON should normalise that case rather than assuming the shape — it is the single most common source of bugs when moving data between the two formats.

Escaping, which is where hand-written converters break

Text going into XML has to have its ampersands, less-thans and greater-thans replaced with entities, and attribute values need their quotes escaped as well. Miss one and the document is not merely wrong, it is unparseable — a stray & in a URL inside an element is enough to break the whole file. Coming back, entities have to be decoded, including numeric ones in both decimal and hexadecimal form, and CDATA sections must be taken literally rather than decoded again.

All of that is handled here, and it is the practical reason to use a converter rather than assembling XML with string concatenation. The output is also indented rather than emitted on one line, since a document that a person has to read is worth more than four saved bytes.

Which format to use, if you have the choice

For a new API, JSON, almost always — it maps directly onto the data structures of every language people write clients in, and it carries no ceremony. XML earns its keep where documents rather than data are the subject: mixed content where markup is interleaved with prose, schema validation that has to be enforced by a third party, digital signatures over part of a document, and the many established formats built on it, from RSS and SVG to invoicing standards that industries have standardised on.

Most conversions are not a choice between them at all, but a bridge: an established system speaks one and a new one speaks the other. In that situation the important thing is not which format is better, but that the mapping is explicit, documented and reversible — which is what the convention on this page is for.

Frequently asked questions

Why does the converter need a convention at all?
Because the two formats have different shapes and something has to bridge the gap. XML carries attributes, comments, namespaces, processing instructions and ordered mixed content; JSON carries objects, arrays and four scalar types. There is no mapping that preserves everything in both directions, which is why BadgerFish, Parker, GData and several others exist and all disagree. Naming the convention is what lets you predict the output and write code against it.
What happens to a JSON key that is not a legal XML element name?
It is sanitised and you are told. XML names have to start with a letter or an underscore and may then contain letters, digits, hyphens, full stops and underscores, so a key like "2024" or "order id" cannot be used directly — the first becomes _2024 and the second becomes order_id. The rename is reported in a warning rather than performed silently, because a quietly renamed element in a document that another system has to parse is a much worse failure than an error message.
Why is type conversion off when reading XML?
Because XML text is always text and the document does not record what it was meant to be. Converting "42" to a number is usually right and occasionally destructive: a postcode, a part number or a phone number with a leading zero loses that zero and becomes a different value, and version strings like "1.10" turn into 1.1. With the option off, everything arrives as a string and you decide; with it on, only values that survive a round trip through Number unchanged are converted, so leading zeros are still left alone.
Is anything lost converting XML to JSON?
Comments, processing instructions and the XML declaration are dropped, and you get a warning saying how many. JSON has nowhere to put them, and inventing a key would break the symmetry that makes the round trip work. Namespace prefixes survive as part of the element name rather than as namespaces proper, so a document that relies on prefix rebinding will not round-trip faithfully. Element order within a parent is preserved for repeated elements but not guaranteed across different keys, since JSON objects are unordered by definition.
Does my data leave the browser?
No. The parsing and generation both run in JavaScript on your machine — there is no request to a server, and nothing is stored. That is worth knowing because the documents people convert are frequently exports containing customer records, orders or API payloads, and a converter that posts them somewhere to do the work has taken a copy.

Related tools