· 6 min read
Converting JSON to XML is not the flattening problem that converting to CSV is, because XML can represent a tree just as JSON can. What changes instead is more structural: XML requires exactly one root element, a JSON array has to become repeated child elements, and not every JSON key is a legal XML tag name. Those three decisions, plus what happens to types, are the whole conversion.
TL;DR: the nesting survives. What a JSON to XML converter actually has to decide is the wrapper element for a top-level array or object, the repeated tag name for array items, and a substitute for any key that is not a valid XML name. Numbers and booleans become text either way, since XML has no type system of its own either.
A JSON document can be a bare array or object with nothing wrapping it. XML cannot: every well-formed document has exactly one top-level element, and everything else nests inside it. A converter has to invent that element, commonly something generic like root or the name of the field the data came from. There is no source information to derive it from, so it is worth checking what your converter chose rather than assuming it matches your schema.
XML has no array type, only elements that can repeat under the same parent. An array of three objects becomes three sibling elements with the same tag name, one per item, rather than a single array-shaped node. That tag name is usually a singular form of the array's key, or another generic default, and it is the detail most worth checking, because two converters can pick different names for the same array and produce structurally different XML from the same JSON.
An XML element name cannot contain a space, cannot start with a digit, and cannot start with the letters xml in any case. A JSON key like "first name", "2024-total", or "xmlns" is common in real data and illegal as a tag name unmodified. A converter has to substitute something, usually an underscore for the space and a prefix for a name starting with a digit, and that substitution is a lossy, converter-specific choice rather than part of the JSON to XML mapping itself.
| JSON | Typical XML rendering | What to check |
|---|---|---|
| Top-level array or object | Wrapped in one invented root element | The root element's name, since nothing in the JSON supplies one |
| Array of objects | Repeated sibling elements, one per item | The repeated tag name, which varies by converter |
| Key with a space, e.g. "first name" | Renamed, usually with an underscore | Whether the renamed tag still matches what a consumer expects |
| Key starting with a digit | Prefixed, since XML names cannot start with a digit | The exact prefix the converter chose |
| Number or boolean | Text content, same as everywhere else | Nothing lost here that CSV would not also lose |
| null | An empty element, or the key omitted | Whether your consumer treats those the same way |
JSON has one way to attach a value to a key. XML has two: a child element or an attribute on the parent element, and nothing in a JSON document says which one a value should become. Most general-purpose converters put every value into a child element and leave attributes unused, which is the safer default because it does not require guessing which fields are metadata. If the XML you need has to match a specific schema that expects attributes, that is a manual step after conversion, not something a generic converter can infer.
The same reasoning applies as for any other conversion here: JSON worth converting to XML is usually a real export or a real API response, which means real records. Converting it with a tool that parses the document in your own browser tab means it is never sent anywhere as a request. Load the page, disconnect from the internet, and a browser-side converter keeps working, which is the direct way to check rather than reading a privacy policy.
Try it or go deeper
No. XML represents a tree natively, so nested objects and arrays keep their structure. What changes is the wrapper root element, the tag name used for repeated array items, and any key that is not a valid XML name.
XML requires exactly one root element, and a JSON document can be a bare array or object with no wrapper. The converter has to invent that outer element since the JSON does not supply one.
It gets renamed, since XML element names cannot contain spaces or start with a digit. The exact substitution, usually an underscore or a prefix, is converter-specific rather than a fixed rule.
No. Like CSV, XML has no native number or boolean type, so every value becomes text content and a consumer has to parse it back into a type on the other side.
Not with a browser-side tool. The document is parsed by the JavaScript already running in your tab, which you can confirm by disconnecting from the internet and converting again.