JSON to XML Converter Online

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.

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.

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.

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.

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.