How to Convert JSON to XML
Paste JSON and set the root and array-item tags. Review the XML preview before copying or downloading it. A JSON-to-XML conversion needs conventions because JSON keys, XML elements and attributes are not identical concepts.
Mapping JSON Objects and Arrays to XML
Objects become nested elements and array entries use repeated item tags. A wrapper root keeps the document well-formed. Review names that are valid JSON keys but invalid XML element names.
Root Tags, Item Tags and Attributes
The root tag names the outer document element and the item tag names array entries. Attributes require a mapping convention rather than an automatic one-to-one translation. Check what the receiving system expects before exporting.
JSON to XML Examples
The object {"name":"Ada","active":true} becomes child elements under the chosen root. Reserved markup characters in text must be escaped. A null may become an empty element rather than a typed JSON null.
JSON vs XML for APIs
JSON is often convenient for typed application payloads while XML supports attributes, namespaces and mixed content. Conversion changes representation and may not round-trip every distinction. Validate against the receiving API contract.
More examples and technical details
The Mapping Rules
JSON and XML both describe trees, so the conversion is more natural than flattening to a spreadsheet. Three rules cover almost every case.
- An object key becomes an element name, and the value becomes that element's content.
- An array becomes a set of repeated sibling elements sharing one name, because XML has no array literal. The array itself is invisible in the output.
- A primitive becomes text content. Numbers and booleans lose their type and become plain characters, since XML without a schema has no types.
The array rule is the one with consequences. Since the brackets vanish, an array of one element and a bare object produce identical XML. That ambiguity is why converting back from XML to JSON needs either a schema or a convention.
Side by Side Example
A small product catalogue, shown as JSON and as the XML it produces.
JSON input
XML output
Element Naming Constraints
JSON keys are arbitrary strings. XML element names are not, and this is where most conversions actually break. An XML name must start with a letter or an underscore, may not start with a digit, may not contain spaces, and may not begin with the sequence xml in any casing, which is reserved.
| JSON key | Valid element? | Typical transformation |
|---|---|---|
| firstName | Yes | firstName, used unchanged |
| first name | No, space | first_name or firstName |
| 1st | No, leading digit | _1st or n1st |
| order-total | Yes | Hyphens are legal after the first character |
| user.id | Yes but risky | Full stops are legal but read as a path by some tooling |
| xmlData | No, reserved prefix | x_xmlData |
| (empty string) | No | item or a positional fallback |
| price (£) | No, space and symbol | price_gbp |
Pick one transformation policy and apply it consistently, because the mapping needs to be predictable if anything downstream will parse the result.
Attributes Versus Child Elements
This is the design decision with no correct answer, and JSON gives you no hint either way because it has only keys and values. The same data can be modelled both ways.
Two valid encodings of the same record
The usual guidance is that attributes carry metadata about the element (identifiers, units, language codes, flags) while child elements carry the content itself. Attributes cannot repeat, cannot nest, and cannot hold structure, so anything that might grow later belongs in an element. Converters default to all elements because it is the only choice that never loses the ability to expand a value into a subtree.
Declaration, Escaping, and the Single Root
A well formed XML document conventionally opens with a declaration naming the version and the character encoding. It is optional in XML 1.0 but including it removes any doubt about how the bytes should be decoded.
Five characters have special meaning inside XML and must be replaced with their predefined entities when they appear in text content.
| Character | Entity | Required in |
|---|---|---|
| < | < | Text content and attribute values |
| > | > | Text content, recommended everywhere |
| & | & | Text content and attribute values |
| " | " | Attribute values quoted with double quotes |
| ' | ' | Attribute values quoted with single quotes |
Missing the ampersand is the classic failure. A company name such as Marks & Spencer produces a fatal parse error, not a warning, because the parser reads the ampersand as the start of an entity reference.
Exactly one root element
XML requires a single outermost element. JSON has no such rule, so a top level array has nowhere to go and needs a synthetic wrapper. An array of three orders becomes an orders element containing three order elements. Choose the wrapper name deliberately, since it becomes part of the contract for anything reading the document, and a generic name like root tells the consumer nothing.
XML is rarely the last stop. Explore the full converter collection for XML to JSON to reverse the transformation, JSON to YAML when the target is a config file rather than a document, and JSON Schema when you need validation rules similar to what an XSD would give you.
Standards and references
Frequently asked questions
How do I convert JSON to XML?
Paste JSON, choose root and item tags, then copy or download XML.
How are JSON arrays represented in XML?
Array entries become repeated item elements inside their containing element.
Can I choose the XML root tag?
Yes. Use the root-tag setting.
What happens to null values?
Null is emitted as an empty element; XML has no universal built-in JSON-null representation.
Is conversion client-side?
Yes. The conversion happens in this tab.