JSON to XML: Mapping Modern Data into a Legacy Format
Why You Still Need JSON to XML
JSON won the web API war years ago, but XML never really left. SOAP services, RSS and Atom feeds, sitemaps, Office Open XML (DOCX, XLSX), Android resources, Maven and Gradle configs, OPML, KML, SVG, RSS, and a long tail of enterprise B2B integrations all speak XML. The moment your modern JavaScript or Python service has to talk to one of them, you need a clean JSON-to-XML bridge.
The conversion sounds simple — both formats are hierarchical, after all — but there are real design decisions to make, and most online tools get them wrong (or don't expose them at all).
The Three Mapping Problems
1. JSON arrays have no XML equivalent
XML has no native array type. The standard convention is to use **repeated sibling elements with the same tag**:
```json
{"catalog": {"book": [{"id": "bk101"}, {"id": "bk102"}]}}
```
becomes:
```xml
<catalog>
<book><id>bk101</id></book>
<book><id>bk102</id></book>
</catalog>
```
Notice that there's no `<book>` array wrapper — the two `<book>` elements just sit as siblings inside `<catalog>`. That's the idiomatic XML shape, and the one downstream consumers expect. Our [JSON to XML converter](/json-to-xml) does this automatically.
2. Attributes vs elements
XML supports both `<book id="bk101">` (attribute) and `<book><id>bk101</id></book>` (child element). JSON has no equivalent distinction — both look like a key on the parent object. There's no unambiguous way to decide which JSON keys should map to attributes.
Most tools take a pragmatic stance: **everything becomes an element**. It's verbose, but it's predictable and round-trips cleanly. If you need attribute output, post-process with XSLT or rename specific keys in your downstream pipeline.
3. Escaping special characters
XML reserves five characters: `<`, `>`, `&`, `"`, `'`. If any of them appear in your JSON values, they **must** be escaped to entity references (`<`, `>`, `&`, `"`, `'`). Forget this and you'll produce XML that crashes the next parser that reads it.
This is where home-grown converters fall apart. A name field with `Smith & Jones` becomes invalid XML if the `&` isn't escaped. A description containing `<b>bold</b>` becomes invalid (and a silent security risk) if the angle brackets aren't escaped.
Element Name Sanitization
XML element names follow strict rules: must start with a letter or underscore, can contain letters, digits, hyphens, periods and underscores — but no spaces, slashes, or special characters. JSON keys have no such restrictions. A key like `"first name"` or `"123-abc"` can't be used as an XML tag directly.
Good converters sanitize automatically: replace invalid characters with underscores, prefix a leading underscore to keys that start with a digit. The XML stays well-formed; the original key shape is documented somewhere in the conversion process.
Picking a Root Element
Every XML document must have exactly one root element. If your JSON is a single-keyed object like `{"catalog": {...}}`, the natural choice is to use `catalog` as the root. If your JSON is an array or a multi-keyed object, you need to wrap it — that's where the "Root element" option comes in. Common choices: `<root>`, `<response>`, `<envelope>`, or a domain-specific name like `<rss>` or `<catalog>`.
To Declare or Not to Declare
The `<?xml version="1.0" encoding="UTF-8"?>` line at the top is the **XML declaration**. It's recommended for standalone XML files but should be omitted when embedding XML inside another document (an HTML page, a SOAP envelope, an email body). Most tools should let you toggle this.
A Concrete Example
Input JSON:
```json
{
"catalog": {
"book": [
{"id": "bk101", "title": "XML Developer's Guide", "price": 44.95}
]
}
}
```
Output (2-space indent, with declaration):
```xml
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book>
<id>bk101</id>
<title>XML Developer's Guide</title>
<price>44.95</price>
</book>
</catalog>
```
Notice the apostrophe in `Developer's` was escaped to `'` automatically — that's the kind of detail that breaks naive implementations.
When XML Isn't the Right Target
If you have a choice (you're designing the interface, not integrating with an existing one), JSON is almost always the better target: simpler grammar, native types, less verbose, and supported everywhere modern XML is. Use XML when you have to — legacy systems, document formats, or specs that mandate it (sitemaps, RSS, SOAP). Otherwise stick with JSON.
Conclusion
JSON to XML isn't trivial: arrays have no native equivalent, special characters must be escaped, element names need sanitizing, and you have to pick a root. A good converter handles all of these by default and exposes the few options that genuinely depend on context (root name, indent, declaration). Our [JSON to XML converter](/json-to-xml) does exactly that — paste, click, get well-formed XML.