Convert JSON to XML with a clear mapping

Know the mapping before export

With a valid XML name, an object key becomes a nested element. Array entries repeat as item elements below their parent. Scalars and null become element text. An invalid XML key takes a different route: an entry element carries the original key in an attribute.

That fallback is important. A JSON key such as 1bad or bad key cannot simply become <1bad> or <bad key> in well-formed XML.

Copyable XML output

{
  "valid": {
    "title": "A&B report",
    "bad key": null,
    "arr": [true, false, 3]
  },
  "1bad": "ok"
}

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <valid>
    <title>A&amp;B report</title>
    <entry key="bad key">null</entry>
    <arr>
      <item>true</item>
      <item>false</item>
      <item>3</item>
    </arr>
  </valid>
  <entry key="1bad">ok</entry>
</root>

Export XML

1. Open the JSON source in JSON All-in-One.
2. Shape the source if only one subtree should become the XML document.
3. Choose Export, then XML.
4. Review the generated root element and fallback entry key elements.
5. Validate well-formedness with a separate XML parser before sending the file to the receiving system.

Review element names deliberately

XML naming rules are stricter than JSON object keys. A JSON key can contain spaces, punctuation, start with a number, or repeat patterns that are awkward in XML. The fallback entry key shape keeps the original key visible, but it may not match a partner system that expects a named element.

Compare at least one invalid-name key and one valid-name key side by side before you send XML to a receiver. That makes the mapping visible instead of leaving the first rejection to happen in a partner system.

Well-formed XML is not schema compliance

A parser can accept an XML document that your partner, enterprise system, or XSD rejects. XML schemas may require attributes instead of child elements, specific namespaces, ordered children, different root names, or a particular representation for nulls.

The JSON source usually does not contain those XML-only decisions. If the receiver has a schema, compare the generated document against that schema and adjust the JSON shape or use a purpose-built mapping step.

Before sending the file, check the root name, array item names, null representation, text escaping, and any attributes required by the receiving system. Validate against the receiver's schema when one is provided.

Arrays and nulls need special review

Repeated array items are easy for humans to read, but the receiver may expect a different element name than item. Null is visible as text in the output above, but some XML contracts prefer an omitted element, an empty element, or a namespaced nil attribute.

Keep the original JSON when structure, types, or precision matter. Converting to XML does not guarantee that a later conversion back to JSON will reconstruct the same data.

If the handoff is for a partner API, ask for a minimal accepted XML example from that partner. Compare it against the exported XML before you send real data. The closer the fixture is to the receiver's contract, the fewer surprises you will have with names, arrays, and nulls.

• Use CSV for tabular handoffs
• Use YAML for readable configuration
• Compare all export formats