How are JSON arrays represented in XML?

Each array item becomes its own sibling element using the array's key as the tag name, rather than a single wrapper element containing a list. "tags": ["a", "b"], for example, becomes a b , two separate elements at the same nesting level, not a element containing two children. This mirrors how most hand-written XML represents repeated data (RSS items, SOAP array parameters), so the output looks like something a person would actually author instead of inventing a synthetic container element with no equivalent in the source JSON. It also means arrays of objects repeat the whole object structure per item. An array of two user objects produces two full ... blocks back to back, each with its own nested children.

Can I choose the root element name?

Yes. There's a root element field above the input panel, defaulting to 'root', that controls the single top-level tag every other element nests inside. Setting it to match what a receiving system expects, for a typical API wrapper, say, or for a generic payload, saves a manual find-and-replace after copying the output. The root name is validated the same way any other key is. If you type something that isn't a legal XML element name, the converter falls back to a safe generic name rather than emitting invalid markup, so double-check the root element in the output matches what you typed if you used unusual characters.

What happens to keys that aren't valid XML tag names?

Keys that don't satisfy XML's rules for element names (containing a space or a symbol like & or #, or starting with a digit) get replaced with a generic 'item' tag instead of being dropped or causing the whole conversion to fail. This keeps the output well-formed no matter what the source JSON's key names look like, but it's a lossy fallback. If several sibling keys all fail validation, they all become , and the original key names are gone from the output entirely, recoverable only by comparing against the source JSON. If your JSON has keys like this and you need them preserved in the XML, rename them to valid XML names (letters, digits, underscores, hyphens, periods, not starting with a digit) before converting.

Does the converter support XML attributes?

No, every JSON key becomes a child element rather than an XML attribute, even for primitive values that another converter might represent as attribute="value". That's a deliberate choice. JSON has no built-in concept distinguishing "this should be an attribute" from "this should be a child element", so any JSON-to-XML converter that produces attributes has to guess or rely on a naming convention (like a leading @ on the key). Always using child elements avoids that ambiguity entirely and makes the mapping from JSON shape to XML shape fully predictable, the same JSON structure always produces the same XML structure, regardless of the specific keys or values involved. If your target system specifically requires attributes, you'll need to restructure the output by hand afterward.

Is my JSON data uploaded to a server?

No. The conversion runs entirely in your browser. Your JSON gets parsed with JSON.parse() and walked recursively to build the XML string, all in client-side JavaScript, with no backend endpoint this page calls to do the work. Nothing about your input, your chosen root element name, or the resulting XML gets sent over the network, logged, or stored anywhere. That matters for anyone converting internal API payloads, config data, or anything containing hostnames, IDs, or other details you wouldn't want leaving your machine just to reformat it. Watch your browser's network panel while converting if you want to confirm it yourself, there's no request tied to the data you pasted.

How does this differ from the JSON to YAML converter?

Both take the same JSON input and re-serialize it in a different text format, but the formats themselves serve different purposes. XML is what legacy enterprise systems, SOAP services, and some older CI or build tools expect, and it supports constructs like attributes and namespaces (though this converter doesn't generate them) that YAML has no equivalent for. YAML is the format modern config and manifest tooling favors, Kubernetes, GitHub Actions, docker-compose, because it's more compact and readable for hand-edited files, at the cost of being whitespace-sensitive in a way XML isn't. If you're not sure which one you need, it usually comes down to what's already reading the file. Pick XML if the consumer is an XML parser or an XML-only system, pick YAML if it's a YAML-based tool or you mainly want something readable.

What happens when the top-level JSON value is an array?

The converter repeats the root element once per array item rather than wrapping them in a single root, so [{"id":1},{"id":2}] produces two full ... blocks concatenated one after another. That output isn't well-formed XML. The XML specification requires exactly one root element per document, and a document with two top-level elements gets rejected by a strict XML parser, even though each individual block is internally well-formed. If your JSON's top-level value is an array, wrap it in an object first, {"items": [...]} for example, so the array becomes a single nested element with repeated children inside one root, instead of converting the bare array directly.

How are null values and empty objects or arrays rendered?

A null value, an empty array ([]), and an empty object ({}) all render the same way: a self-closing tag with no content, like , rather than an empty open/close pair like . Both forms are equivalent under the XML specification, and any conforming parser treats them identically, but the self-closing form is shorter and is what most hand-written and machine-generated XML uses for empty elements. One consequence worth knowing: because all three cases (null, empty array, empty object) collapse to the same self-closing tag, the XML output alone doesn't let you tell which of the three the original JSON value actually was. If that distinction matters downstream, keep the source JSON alongside the XML rather than relying on the XML to recover it.

JSON to XML Converter - Convert JSON Online

Overview

Introduction

Some systems, such as legacy APIs, SOAP services, and certain enterprise integrations, still speak XML instead of JSON. This tool converts modern JSON payloads into well-formed XML without needing a full XML toolchain.

It exists because that gap between formats is still common in practice. A modern service producing JSON often has to talk to an older system that only accepts XML, and writing a one-off script to handle escaping, nested structures, and array representation correctly is more work than it looks like at first. This tool handles that translation directly in the browser, no XML library or build step required.

What Is JSON to XML Converter?

A JSON-to-XML converter recursively walks a JSON value and emits a corresponding tree of XML elements: objects become nested elements, arrays become repeated sibling elements, and primitives become element text content.

There's no single official mapping between JSON and XML the way there's a formal JSON grammar, so different converters make different choices, particularly around arrays and attributes. This one favors predictability. Every JSON key always becomes a child element, never an attribute, so the same JSON shape always produces the same XML shape regardless of what the values happen to be.

How JSON to XML Converter Works

Object keys become element names, and each value is escaped or nested depending on its type. The five reserved XML characters (&, <, >, ", ') get escaped in text content, keys that aren't valid XML names fall back to a generic 'item' tag, and null values or empty arrays and objects render as self-closing tags (<key />) instead of an empty open/close pair.

Arrays are handled by repeating the key rather than introducing a wrapper element. `"tags":["a","b"]` becomes `<tags>a</tags><tags>b</tags>` rather than a single `<tags>` element containing a list. This mirrors how most hand-written XML represents repeated data and avoids inventing a synthetic container element that wouldn't exist in the equivalent hand-authored document.

When To Use JSON to XML Converter

Use it when you need to feed JSON data into a system that only accepts XML, generate a quick XML sample for testing, or migrate a JSON-based config into an XML-based one.

It's also a fast way to produce a starting XML fixture for testing an XPath query, an XML parser, or a SOAP client. Hand-typing well-formed, properly escaped XML for a moderately nested object is slow and easy to get wrong, particularly around entity escaping.

Often used alongside JSON to CSV Converter, JSON to YAML Converter and JSON Formatter & Beautifier.

Features

Advantages

Produces well-formed, properly escaped XML from arbitrary JSON shapes.
Configurable root element name to match target schema expectations.
Handles arrays, nested objects, and primitives without manual mapping.
Runs entirely in the browser, so there's no server round-trip for potentially sensitive data.

Limitations

Does not generate XML attributes: every value becomes a child element.
Not schema-aware; it won't validate against a target XSD or DTD.
Keys with invalid XML characters are replaced with a generic tag name, which can reduce readability for unusual key names.

XML vs. JSON: When to Use Each

XML vs. JSON: When to Use Each
	XML	JSON
Required by	SOAP services, legacy enterprise systems	Modern REST APIs
Supports attributes and namespaces	Yes	No, only key-value pairs
Schema validation options	XSD, DTD	JSON Schema
Best for	Integrating with XML-only systems	Lightweight, human-readable APIs

Examples

Simple nested object

Input

{"user":{"name":"Ada","age":30}}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <user>
    <name>Ada</name>
    <age>30</age>
  </user>
</root>

Each object key becomes a nested XML element under the configurable root, with two-space indentation reflecting the nesting depth.

Array of primitives

Input

{"tags":["admin","editor"]}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <tags>admin</tags>
  <tags>editor</tags>
</root>

Each array item becomes its own <tags> element instead of a single element holding a list.

Array of objects

Input

{"users":[{"id":1,"name":"Ada"},{"id":2,"name":"Bo"}]}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <users>
    <id>1</id>
    <name>Ada</name>
  </users>
  <users>
    <id>2</id>
    <name>Bo</name>
  </users>
</root>

The whole object structure repeats per array item: two full <users> blocks, each with its own <id> and <name> children, rather than one <users> element containing both.

Null and empty values

Input

{"middleName":null,"tags":[],"address":{}}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <middleName />
  <tags />
  <address />
</root>

A null value, an empty array, and an empty object all render identically as a self-closing tag. The XML output alone can't tell you which of the three the original value was.

Escaping special characters

Input

{"note":"Tom & Jerry <says> \"hi\" it's fine"}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <note>Tom &amp; Jerry &lt;says&gt; &quot;hi&quot; it&apos;s fine</note>
</root>

All five reserved XML characters (&, <, >, ", ') are escaped to their entity form in text content, so the value stays inside a single well-formed <note> element instead of accidentally introducing new markup.

Keys that aren't valid XML names

Input

{"2fa":true,"first name":"Ada"}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <item>true</item>
  <item>Ada</item>
</root>

Both "2fa" (starts with a digit) and "first name" (contains a space) fail XML's name rules, so both fall back to the generic <item> tag. The original key names aren't recoverable from the XML alone.

Invalid JSON input

Invalid input

{"a": 1,}

Parser error

SyntaxError: Expected double-quoted property name in JSON at position 8 (line 1 column 9)

The converter parses your input with JSON.parse() before building any XML, so a syntax error like a trailing comma gets reported immediately rather than producing partial or malformed markup.

Corrected version

{"a": 1}

Best Practices & Notes

Best Practices

Set a meaningful root element name that matches what the receiving system expects.
Validate the resulting XML against your target schema (XSD) separately if strict compliance is required.
Keep JSON key names XML-friendly (no spaces or symbols) for the most readable output.
Wrap a top-level JSON array in an object before converting, {"items": [...]}, say, so the output has a single root element instead of several concatenated <root> blocks that aren't well-formed as one document.
If a key falls back to the generic <item> tag, rename that key in the source JSON to a valid XML name rather than fixing it in the XML output, since regenerating after a rename is more reliable than hand-patching.
When converting data that will be parsed downstream, keep a copy of the source JSON alongside the XML if the distinction between null, an empty array, and an empty object matters, since all three collapse to the same self-closing tag in the output.

Developer Notes

The converter escapes text content with the five standard XML entities (&, <, >, ", ') and validates element names against a practical subset of the XML Name production (a letter or underscore, followed by letters, digits, underscores, hyphens, or periods), falling back to a generic <item> tag when a key wouldn't produce well-formed markup on its own. Arrays are flattened by repeating the parent tag name rather than introducing a synthetic wrapper element, which keeps the shape close to hand-authored XML but means the tag name alone can't distinguish "one value" from "one item in a longer array" without looking at siblings. Null values, empty arrays, and empty objects all take the same self-closing-tag code path, since none of them have children to emit, that's a size-and-simplicity tradeoff, not an attempt to preserve the original JSON type through the XML alone. Because the whole conversion is a synchronous, single-pass recursive walk over the parsed value with no network round trip, converting even a several-hundred-key JSON document happens in milliseconds entirely inside the browser tab.

JSON to XML Converter Use Cases

Wrapping JSON data in the XML envelope a SOAP web service expects
Producing sample XML fixtures to test an XPath query or XML parser
Converting a JSON build config to XML for a tool that only reads XML (some CI systems and legacy build tools)
Generating XML for RSS/Atom-style feeds from a JSON content source
Migrating a JSON-based settings file to an older XML-based configuration format
Producing a quick XML sample to hand to a teammate integrating with an XML-only endpoint

Common Mistakes

Expecting JSON keys to become XML attributes, when they always become child elements instead.
Forgetting to rename the root element, resulting in generic <root> tags that don't match the target schema.
Assuming the output is schema-valid for a specific XSD without checking separately.
Converting a top-level JSON array directly and getting multiple concatenated <root> elements, which isn't well-formed XML. Wrap the array in an object first.
Not noticing that a handful of keys collapsed to the generic <item> tag because they contained spaces, symbols, or a leading digit, silently losing those key names from the output.

Tips

If the target system expects a specific root tag (like <response> or <data>), set it before converting rather than editing the XML afterward.
For arrays of primitives, expect repeated sibling elements rather than a single list container: this matches common XML conventions.
If your JSON's top-level value is an array, wrap it in an object with a single key first so the output has one well-formed root element instead of several sibling <root> blocks.
Scan the output for <item> tags after converting, each one marks a key that wasn't a valid XML name and lost its original name in the process.

JSON to XML Converter

Overview

Introduction

What Is JSON to XML Converter?

How JSON to XML Converter Works

When To Use JSON to XML Converter

Features

Advantages

Limitations

XML vs. JSON: When to Use Each

Examples

Simple nested object

Array of primitives

Array of objects

Null and empty values

Escaping special characters

Keys that aren't valid XML names

Invalid JSON input

Best Practices & Notes

Best Practices

Developer Notes

JSON to XML Converter Use Cases

Common Mistakes

Tips

References

Frequently Asked Questions