What becomes the root element?

If your JSON is an object with exactly one top-level property, that property names the root — which is what makes the conversion reversible. Anything else has no name of its own, so it is wrapped in an element you can rename, and you get a warning saying so.

How do I produce attributes rather than child elements?

Prefix the property name with @. {"user":{"@id":"1","name":"Ada"}} produces Ada . A property called #text becomes the element's text content. These are the same conventions the XML to JSON converter reads, so the two round-trip.

What happens to property names that are not valid XML names?

XML element names cannot contain spaces and cannot start with a digit. A name like "first name" is renamed to first_name and "1st" to _1st — and every rename is listed in a warning. Renaming silently would be a wrong answer; refusing outright would make the tool useless on ordinary JSON.

How are arrays represented?

As repeated elements sharing the parent's name, which is how XML expresses a list. {"line":["a","b"]} becomes a b . An empty array becomes a single empty element.

Will long numbers survive?

Yes. Numbers are written from the exact digits in your JSON rather than being read into a JavaScript number, so a 20-digit identifier is copied across character for character.

Can this produce a SOAP envelope?

Not directly — SOAP needs a namespaced / wrapper the converter has no way to infer from plain JSON. Set the wrapper element to your operation name (e.g. "GetOrderResponse"), convert, then paste the result inside your own envelope template. The @-prefix convention still gets you the xmlns and other attributes SOAP requires on the way in.

What happens to duplicate keys or mixed content?

JSON objects can't carry two properties with the same name, so there's nothing to collapse there — but XML can express things JSON has no shape for, such as an element that has both text and child elements interleaved (mixed content). This converter only goes one direction (JSON → XML), so that case doesn't arise here; it's the XML to JSON converter that has to decide how to represent it, and it warns when it does.

Does it validate the XML against a schema?

No — it guarantees the output is well-formed (properly nested, escaped and closed), which is a lower bar than valid against a specific XSD or DTD. If your target system expects a particular schema, check the element names and structure against it after converting; the tool has no way to know what schema you're aiming for.

This tool runs entirely in your browser. Nothing you paste is uploaded.

How you can check →

JSON to XML

JSON

Convert JSON into well-formed, indented XML in your browser — with attribute support, and every renamed field reported rather than silently changed.

JSON

Wrapper element

Array items

Indent

Include the XML declaration

XML

The XML appears here.

How JSON maps onto XML

XML is the older and stricter of the two formats, and it demands things JSON never asks for: exactly one root element, names that follow a specific grammar, and text that escapes a handful of characters. The conversion is mostly a matter of supplying those requirements without changing what the document says.

An object becomes an element, with one child element per property.
An array becomes repeated elements sharing the property's name, which is how XML represents a list — there is no separate array construct.
A property prefixed with @ becomes an attribute on the parent element instead of a child.
A property named #text becomes the element's text content, so an element can carry both attributes and a value.
null and empty containers become empty elements (<a/>).
&, < and > are escaped in text; attribute values also escape quotes, newlines and tabs so they survive re-parsing.

Choosing the root

An XML document must have exactly one root element, and JSON has no equivalent requirement. If your document is an object with a single top-level property, that property becomes the root and the conversion is reversible — running the result back through the XML to JSON converter returns what you started with. If it is an array, or an object with several top-level properties, there is no name to use, so it is wrapped in the element named in the Wrapper element box and a warning explains that this happened.

Names that XML will not accept

JSON property names are arbitrary strings. XML element names may not contain spaces, may not begin with a digit, and are restricted to a defined character set. Real JSON is full of names like first name and 2024_total that break those rules.

Rather than failing on documents that are perfectly ordinary, this converter substitutes underscores for characters that cannot appear and adds a leading underscore where a name may not start with the character it has — so 1st becomes _1st rather than losing the digit. Every rename is listed in a warning, because a field that changed name without telling you is precisely the kind of quiet wrongness that costs an afternoon.

What XML can express that JSON can't, and vice versa

The two formats aren't a strict superset of each other, which is why this conversion needs conventions rather than being automatic. XML has no native number, boolean or null type — every value is text, and it is up to whatever reads the document to know that qty should be parsed as an integer. JSON, in turn, has no attribute concept and no ordering guarantee between distinct properties the way XML elements are strictly ordered as written. The @-prefix and #text conventions used here exist specifically to carry the attribute/element distinction through a format that has no separate slot for it.

Producing a SOAP-style payload

SOAP envelopes are XML with a specific namespaced wrapper (<soap:Envelope>, <soap:Body>) around an otherwise ordinary document. This converter doesn't fabricate a namespace it wasn't told about, but the same @ convention that produces attributes generally is what produces the xmlns declarations SOAP needs — set them as @xmlns-prefixed properties on the object that becomes your envelope's root, and the converter treats them like any other attribute.

Common uses

Producing a SOAP or legacy-system payload from a modern JSON API response
Generating a fixture for a system that only ingests XML
Checking how a JSON structure would look in a schema-driven format
Round-tripping a document to see which parts of it XML cannot express
Feeding a config-management or CI tool whose input format is fixed to XML

Frequently asked questions

What becomes the root element?: If your JSON is an object with exactly one top-level property, that property names the root — which is what makes the conversion reversible. Anything else has no name of its own, so it is wrapped in an element you can rename, and you get a warning saying so.
How do I produce attributes rather than child elements?: Prefix the property name with @. {"user":{"@id":"1","name":"Ada"}} produces <user id="1"><name>Ada</name></user>. A property called #text becomes the element's text content. These are the same conventions the XML to JSON converter reads, so the two round-trip.
What happens to property names that are not valid XML names?: XML element names cannot contain spaces and cannot start with a digit. A name like "first name" is renamed to first_name and "1st" to _1st — and every rename is listed in a warning. Renaming silently would be a wrong answer; refusing outright would make the tool useless on ordinary JSON.
How are arrays represented?: As repeated elements sharing the parent's name, which is how XML expresses a list. {"line":["a","b"]} becomes <line>a</line><line>b</line>. An empty array becomes a single empty element.
Will long numbers survive?: Yes. Numbers are written from the exact digits in your JSON rather than being read into a JavaScript number, so a 20-digit identifier is copied across character for character.
Can this produce a SOAP envelope?: Not directly — SOAP needs a namespaced <soap:Envelope>/<soap:Body> wrapper the converter has no way to infer from plain JSON. Set the wrapper element to your operation name (e.g. "GetOrderResponse"), convert, then paste the result inside your own envelope template. The @-prefix convention still gets you the xmlns and other attributes SOAP requires on the way in.
What happens to duplicate keys or mixed content?: JSON objects can't carry two properties with the same name, so there's nothing to collapse there — but XML can express things JSON has no shape for, such as an element that has both text and child elements interleaved (mixed content). This converter only goes one direction (JSON → XML), so that case doesn't arise here; it's the XML to JSON converter that has to decide how to represent it, and it warns when it does.
Does it validate the XML against a schema?: No — it guarantees the output is well-formed (properly nested, escaped and closed), which is a lower bar than valid against a specific XSD or DTD. If your target system expects a particular schema, check the element names and structure against it after converting; the tool has no way to know what schema you're aiming for.

XML to JSON

Convert XML to JSON with the mapping rules stated, not hidden.

JSON Formatter & Validator

Format, minify and validate JSON without your numbers changing.

JSON to CSV

Flatten JSON into spreadsheet columns, with long numbers intact.