JSON to XML

Example: repeated elements

Input:

{ "users": [ { "name": "Alice" }, { "name": "Bob" } ] }

Output:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <users>
    <name>Alice</name>
  </users>
  <users>
    <name>Bob</name>
  </users>
</root>

Example: array wrapper

Same input with the “wrap arrays in <item>” strategy:

<root>
  <users>
    <item>
      <name>Alice</name>
    </item>
    <item>
      <name>Bob</name>
    </item>
  </users>
</root>

Type mapping

Attributes vs elements

XML distinguishes attributes (<user id="1">) from child elements (<user><id>1</id></user>). The converter defaults to elements, they are lossless for round-tripping. If your downstream XML requires attributes, use a key prefix convention:

• JSON key @id becomes an XML attribute id="..." on the parent element.
• JSON key #text becomes the text content of the parent element.

These conventions come from BadgerFish and Parker mappings, the two most common JSON-to-XML standards.

Escaping rules

• < -> <
• > -> >
• & -> &
• " -> " (in attribute values)
• ' -> ' (optional)
• Bytes in UTF-8 are preserved, declared in the XML prolog.

Common mistakes

• Root-level JSON array. XML needs a single root element. The converter wraps an array in <root> (or whatever name you choose).
• Numeric keys. JSON {"1": "a"} is legal; XML element names cannot start with a digit. The converter prefixes digits with an underscore (_1) or lets you define a custom mapping.
• Mixed arrays. [1, "two", { "x": true }] has no clean mapping. Usually this means the JSON needs normalization before conversion.
• Huge documents. XML is verbose, a 10 MB JSON can become a 20-30 MB XML. Consider streaming conversion for very large payloads.