JSON to XML Converter

This tool converts JSON to XML in your browser; nothing leaves your machine. For the reverse direction, see XML to JSON.

There’s no canonical mapping

JSON and XML have different data models. Conversion requires choices that aren’t dictated by either spec:

Most converters pick one set of conventions and apply them consistently. The tool above defaults to:

• Object keys → element names
• Array items → repeated elements named after the array’s key; a bare top-level array becomes <item> elements inside <root>
• Primitives → element text content
• Null → empty element

These conventions match the most common JSON-to-XML output in the wild, but they’re not standard.

A typical conversion

JSON:
{
  "user": {
    "name": "Alice",
    "age": 30,
    "tags": ["vip", "active"]
  }
}

Generated XML:
<root>
  <user>
    <name>Alice</name>
    <age>30</age>
    <tags>vip</tags>
    <tags>active</tags>
  </user>
</root>

The outer <root> wraps everything because XML requires a single root element (JSON doesn’t). Object keys become element names; the array’s items each get their own <tags> element. (The tool puts one element per line without indentation; the XML formatter will indent it.)

Why arrays are awkward

JSON arrays are ordered collections; XML doesn’t have a direct equivalent. The most common pattern is repeated elements:

<tags>vip</tags>
<tags>active</tags>

But this loses the “array” intent — when you parse the XML back, you have to know that tags is meant to be a list (with one or many elements) rather than a single string. The reverse conversion (XML to JSON) typically reads two <tags> as a list and one <tags> as a string, which means a one-element array round-trips as a string.

Some converters wrap arrays in a parent element to preserve the structure:

<tags>
  <item>vip</item>
  <item>active</item>
</tags>

This round-trips more reliably but adds verbosity.

Element names for invalid JSON keys

XML element names have rules JSON keys don’t:

• Must start with a letter or underscore.
• Can contain letters, digits, hyphens, underscores, periods.
• Cannot start with xml (reserved).
• Cannot contain spaces or special characters.

JSON keys with hyphens (first-name) work in XML; keys with spaces or starting digits don’t:

JSON: {"first name": "Alice", "1st-choice": "blue"}
XML:
<root>
  <first_name>Alice</first_name>      ← space → underscore
  <_1st-choice>blue</_1st-choice>     ← prefix invalid char with underscore
</root>

The tool above sanitizes invalid characters; the original JSON key is lost. Round-tripping back to JSON gives sanitized keys, not the originals.

Attributes vs elements

A common alternative mapping uses attributes for primitive fields:

JSON:
{"user": {"name": "Alice", "age": 30}}

Element-based XML:
<root><user><name>Alice</name><age>30</age></user></root>

Attribute-based XML:
<root><user name="Alice" age="30" /></root>

Attributes are more compact and conventional in some XML dialects (HTML attributes, RSS, certain XML schemas). They’re inappropriate for nested structure (you can’t have an attribute that’s an object).

The tool above uses elements. To get attributes, put them under an @attributes key: {"user": {"@attributes": {"id": "7"}, "name": "Alice"}} becomes <user id="7"><name>Alice</name></user> — the same convention XML to JSON produces.

XML declaration and namespaces

<?xml version="1.0" encoding="UTF-8"?>
<root>...</root>

The first line is the XML declaration. Optional but conventional. Some XML parsers refuse input without it.

<root xmlns="http://example.com/myns">...</root>

Namespaces qualify element names. JSON has no namespace concept; the converter has nothing to populate. If the target XML schema requires namespaces, add them to the output by hand.

When XML is the right output

• SOAP web services. Still common in enterprise integrations.
• Office Open XML (Word, Excel, PowerPoint files). The internals are XML.
• RSS / Atom feeds. XML by spec.
• Configuration files in some legacy systems. Older tools.
• Schema-validated data interchange where XSD provides validation that JSON Schema doesn’t.

When JSON is the right output:

• Modern web APIs. Almost universally JSON now.
• Document store databases (MongoDB, etc.).
• Anything where size matters — JSON is denser.

For the reverse direction, see XML to JSON. For other JSON conversions, see JSON to YAML, JSON to CSV.

Common pitfalls

• Round-trip loss. JSON → XML → JSON usually doesn’t preserve everything. Single-element arrays become single elements; numbers become strings (XML has no native types). For lossless interchange, JSON → JSON is the right round-trip.
• Encoding issues. XML declares its encoding; the bytes must match. Unicode in element text needs proper encoding.
• Forbidden XML characters. A few low Unicode code points (control characters except tab, newline, carriage return) are forbidden in XML 1.0. The tool above strips them from text and attribute values.
• CDATA sections. Long strings with many special characters are sometimes wrapped in <![CDATA[...]]> for readability. Most converters don’t emit CDATA; round-tripping through CDATA-aware parsers can lose the marker.
• Schema validation. The generated XML doesn’t conform to a specific XSD; for schema-bound interchange, you’ll need to manually align element names, namespaces, and structure.