The Real Limits of JSON→XML Conversion — Where Arrays, Nulls, and Types Break
JSON and XML both represent data as a tree, so it's tempting to assume you can move freely between them. In practice, converting one to the other runs into several spots where it's genuinely unclear how to represent the data. Arrays, null, numeric/boolean types, and the concept of attributes are all things JSON has clear rules for but XML has no standard syntax for — so every JSON→XML converter has to invent its own convention. This guide walks through exactly what those conventions are, and why converting XML back to JSON never fully restores the original information.
1. Arrays: a concept XML simply doesn't have
In JSON, ["a","b","c"] is a first-class array type. XML has no equivalent concept at all — all it offers is the fact that "a tag with the same name can appear more than once under a parent." So every JSON→XML converter fakes arrays by repeating a tag with the same name as the parent key. For example, {"hobbies":["reading","coding"]} becomes <hobbies>reading</hobbies><hobbies>coding</hobbies>. The problem is that looking at the resulting XML alone gives you no certainty that "hobbies was originally an array." XML itself carries no marker distinguishing "this tag just happens to repeat" from "this was an array" — the side converting back has to infer it from the rule "if the same tag appears more than once, treat it as an array." If the array had exactly one element, that inference fails outright, and there's no way to tell whether the original was an array or a single value.
2. Null: the self-closing empty tag convention
JSON's null is a distinct type meaning "explicitly no value." XML has no standard type for this, so converters typically use one of two conventions. One is a self-closing empty tag like <email/>, ended with a closing slash; the other, more sophisticated, is XML Schema's xsi:nil="true" attribute. Most simple browser-based converters go with the former. The catch is that the same <email/> gives you no way to tell, from the XML alone, whether it meant "this was null" or "this was an empty string ("")." In JSON, null and "" are clearly distinct values, but once they've been through XML and back, both collapse into the same empty tag, and there's no way to recover which one it originally was.
{"email": null} and {"email": ""} convert to <email/>. Looking at the XML alone, you can never tell whether the original JSON had null or an empty string.
3. Numbers and booleans: everything flattens to text
JSON has a type system that clearly distinguishes 30 (a number), true (a boolean), and "30" (a string). XML has no such type system — everything between tags is just text. So both {"age":30} and {"age":"30"} convert to the identical <age>30</age>. The side converting XML back to JSON has to look at the text "30" and guess whether it was originally a number or a string, and that guess can diverge from the original data's intent — for example, if a postal code like "04523" gets misread as a number, the leading zero can end up silently dropped.
4. No concept of attributes
XML lets you attach attributes to a tag, as in <person id="1">, but JSON has no notion of "attributes" to begin with. Because of that, JSON→XML converters mostly skip this feature entirely and take the simpler route of turning every JSON key into a child element without exception — id, name, and age all end up as sibling child tags at the same level. That keeps the implementation simple, but it also means none of XML's native expressiveness around attributes (for example, the common practice of choosing element vs. attribute to keep a document more compact) gets used at all.
5. How these limits show up in practice
- Integrating with legacy SOAP/XML APIs: if you convert JSON data to send to a system that expects arrays/null/types to match a specific schema (XSD), a simple converter's output may not match that schema.
- Expectations around round-tripping: don't assume JSON→XML→JSON will give you back exactly what you started with. Single-element arrays, null vs. empty string, and number vs. numeric string are the classic places information gets lost.
- Tag naming rules: if a JSON key starts with a digit or contains spaces, it violates XML's tag-naming rules (must start with a letter, no spaces, etc.) and can produce invalid XML — it's safer to check your key names before converting.
Frequently Asked Questions
Q. How are JSON arrays represented in XML?
A. Since XML has no array syntax, each array element is repeated as a tag with the same name as the parent key. Example: hobbies:["reading","coding"] → <hobbies>reading</hobbies><hobbies>coding</hobbies>.
Q. How is a null value represented?
A. The common convention is a self-closing empty tag ending in a slash (e.g. <email/>). The limitation is that it's indistinguishable from an empty string.
Q. Can XML be converted back to JSON with perfect accuracy?
A. Not perfectly. Whether an array had exactly one element, whether a value was null or an empty string, and whether a value was a number or a numeric-looking string can't be determined for certain from the XML alone — the reverse conversion has to rely on inference.
Q. Are number and boolean types preserved in XML?
A. No. XML treats everything inside a tag as text, so 30 and "30" come out as identical text. Restoring the original type on the way back requires separate type-inference logic.
Q. What if the converted XML comes out invalid?
A. XML tag names can't start with a digit or contain spaces or certain special characters. If a JSON key breaks that rule (e.g. "1st-item"), it gets used as the tag name without validation, which can produce invalid XML — check your key names before converting.