JSON to XML Converter

Why Convert JSON to XML?

While JSON has become the standard for web APIs, XML remains essential in many enterprise systems, legacy integrations, and industry standards. You might need to convert JSON to XML when:

• Integrating with SOAP services — Many enterprise APIs still use XML-based SOAP
• Working with legacy systems — Older applications often expect XML input
• Generating configuration files — Some tools require XML configs (Maven, Android, etc.)
• Industry compliance — Healthcare (HL7), finance (FIXML), and government systems often mandate XML

How JSON Maps to XML

Understanding the conversion rules helps you work with the output:

Objects become elements

{
  "person": {
    "name": "Alice",
    "age": 30
  }
}

<?xml version="1.0"?>
<root>
  <person>
    <name>Alice</name>
    <age>30</age>
  </person>
</root>

Arrays repeat the element

{
  "colors": ["red", "green", "blue"]
}

<root>
  <colors>red</colors>
  <colors>green</colors>
  <colors>blue</colors>
</root>

Primitives become text content

Strings, numbers, booleans, and null values are converted to element text content. Special characters like <, >, and &are automatically escaped.

Conversion Options

• Root element name — Customize the wrapper element (default: "root")
• Indentation — Output is formatted with 2-space indentation for readability
• XML declaration — Includes <?xml version="1.0"?> header

Handling Edge Cases

Empty values

Null values and empty objects become self-closing tags: <field/>

Special characters in keys

JSON keys with spaces or special characters are sanitized to valid XML element names. Characters that aren't alphanumeric, underscore, or hyphen are replaced with underscores.

Deeply nested structures

The converter handles arbitrary nesting depth. Each level adds indentation for readability.

JSON vs XML: Key Differences

Understanding these differences helps when working with converted data:

• No native arrays in XML — Arrays become repeated elements with the same name
• No data types — XML treats everything as text; numbers become strings
• Attributes vs elements — This converter uses elements only; attributes require manual adjustment
• Namespaces — Not generated automatically; add manually if needed

For a detailed comparison, see our JSON vs XML guide.

Programmatic Conversion

Need to convert in code? Here are examples:

JavaScript

// Using xmlbuilder2
import { create } from 'xmlbuilder2';

const json = { name: "Alice", age: 30 };
const xml = create({ root: json }).end({ prettyPrint: true });

Python

import dicttoxml
import json

data = {"name": "Alice", "age": 30}
xml = dicttoxml.dicttoxml(data, root=True, attr_type=False)

Related Tools

• XML to JSON Converter — Convert XML back to JSON
• JSON Validator — Validate your JSON before converting
• JSON to YAML — Alternative format conversion
• JSON vs XML Guide — When to use each format

Frequently Asked Questions

How are JSON arrays converted to XML?

Each array item becomes a separate XML element with the same tag name. For example,["a", "b"] in a key called "items" becomes<items>a</items><items>b</items>.

Can I customize the root element name?

Yes! Use the "Root element" input field above the convert button to specify any valid XML element name.

Does the converter preserve data types?

XML doesn't have native data types like JSON. Numbers and booleans become text content. You'll need to parse them in your application code.

How do I add XML attributes?

This converter creates elements only. To add attributes, manually edit the output or use a library that supports attribute mapping conventions.

Common Mistakes & Pro Tips

• JSON arrays have no obvious XML equivalent — XML has no native array type, so converters typically repeat a wrapper element for each item — [1,2] under a key tags becomes <tags>1</tags><tags>2</tags> or is wrapped as <tags><item>1</item><item>2</item></tags>. The two styles parse differently, so pick the one your downstream schema expects and be consistent.
• JSON keys are not always valid XML element names — XML element names cannot start with a digit, contain spaces, or begin with the reserved prefix xml. A JSON key like "2024 total" or "first name" is invalid as a tag and must be sanitized (e.g. _2024_total) or mapped to an attribute. If a converter emits <2024 total> verbatim, the resulting document will not parse.
• Attributes vs child elements is a design choice, not a rule — Plain JSON has no notion of attributes, so {"id":1,"name":"x"} could become <node id="1"><name>x</name></node> or <node><id>1</id><name>x</name></node>. Many converters use a convention like a leading @ or a special key (@attributes) to mark which fields become attributes. Know the convention so an id field lands where your consumer expects.
• Reserved characters must be escaped or wrapped in CDATA — The characters &, <, and > must be written as &amp;, &lt;, and &gt; in element text, and " plus ' must be escaped inside attribute values. A value like a < b & c will break the document if emitted raw. Converters either entity-encode these or wrap the text in <![CDATA[...]]>; both are valid but CDATA can't be nested.
• null and empty values produce empty or self-closing tags — A JSON null usually becomes an empty element such as <field/> or <field></field>, which is indistinguishable from an empty string unless the converter adds an attribute like xsi:nil="true". If preserving the difference between null and "" matters, choose a converter that emits the nil marker, or post-process the output.