How JSON objects, lists and values become XML
JSON and XML are both trees, but they name things differently. In JSON a value belongs to a key. In XML a value is the text of an element, and every element needs a name and a parent. These rules fill the gaps.
- An object becomes an element and each key a child element: for
{"name": "Ana", "age": 31}the children are<name>Ana</name>and<age>31</age>. - XML needs exactly one root element. If the object has a single key and its value is not a list, that key is the root. Otherwise everything is wrapped in
<root>, so{"name": "Ana", "tags": ["a", "b"]}gives<root><name>Ana</name><tags>a</tags><tags>b</tags></root>. - A list inside an object is written as the same element repeated, named after the key. That is how XML spells a list.
- A list at the top, such as an API response with many records, becomes
<root><item>...</item><item>...</item></root>. A list inside another list has no key to name its items, so those are calleditemas well. - Numbers and booleans are written as text, and both null and an empty string become an empty element.
Attributes, text and namespaces
JSON has no attributes, so the converter uses a convention: a key that starts with @ becomes an attribute of its parent element, and #text holds the text of an element that also has attributes. {"book": {"@id": "bk101", "title": "XML Guide", "price": {"@currency": "EUR", "#text": 12.5}}} becomes <book id="bk101"><title>XML Guide</title><price currency="EUR">12.5</price></book>.
It is the same convention the XML to JSON page uses, so XML you converted to JSON can be turned back. Namespaces work in the same way: a key "@xmlns": "http://www.sitemaps.org/schemas/sitemap/0.9" on the root comes out as an xmlns attribute, so a sitemap's <urlset xmlns="..."> can be written exactly. The converter does not add a DOCTYPE or a schema reference, so add those by hand if the target system needs them.
Pick name instead of @name under XML attributes to turn the convention off. Every key then becomes an element, and a key such as @id is written as _id.
What XML cannot keep, and what to check
- Types. XML holds only text, so the number 12.5 and the string "12.5" produce the same element. A program reading the XML decides what each value means.
- Null and empty text. Both become an empty element such as
<zip/>, and cannot be told apart when the XML is read back. - Empty lists. XML has no way to write a list with no items, so the element is left out and a note says how many.
- Names. XML names must start with a letter or an underscore and cannot contain spaces.
first namebecomesfirst_name,2022becomes_2022anda/bbecomesa_b. A warning gives an example. - Special characters. & and < are escaped, and so are quotes (
"and'), which is valid even if it looks busy. A tab or line break inside an attribute value and a carriage return in text are written as character references (	, and ), because an XML reader would otherwise turn them into spaces or plain line feeds. Control characters that XML forbids are removed, with a warning. - Large numbers. JSON numbers with more than 15 digits can be rounded when read, and a note warns you. Put such IDs in quotes in the JSON to keep every digit.
Keys are written in the order they appear in the JSON, which matters for formats that expect elements in a fixed order.
Where XML is still required
Most new web services use JSON, but XML is still what SOAP services, RSS and Atom feeds, sitemaps, Maven and Android configuration files and many industry and government exchange formats expect. Those formats usually add rules about element order, namespaces and required attributes. This page converts the structure only, so check the result against the schema or documentation of the system that will read it.