JSON to XML Converter

Translating between two data shapes that don't quite match

JSON and XML both describe structured data, but they think about it differently. JSON has four primitive types (string, number, boolean, null) plus objects and arrays, and a value is simply a value. XML has only text and elements, no native notion of "number" or "array," but it adds attributes — metadata pinned to a tag rather than nested inside it. Converting one to the other is therefore not a lossless swap; it is a set of decisions about how each JSON construct should be expressed in tags. This tool makes those decisions explicit through its options, then builds the XML string entirely in your browser.

The rules this converter applies

Each JSON value maps to a tag named after its key. The mapping is consistent and worth knowing:

Because XML tag names cannot start with a digit or contain spaces, the converter sanitizes any key that would be illegal: invalid characters become underscores, and a leading digit gets an underscore prefix. That keeps the output well-formed even when your JSON keys were never meant to be element names.

A worked example

Feed it this JSON:

{ "user": { "name": "Alice", "tags": ["admin", "editor"] } }

With the root element set to root and the array item tag set to item, you get:

<root><user><name>Alice</name><tags><item>admin</item><item>editor</item></tags></user></root>

Notice the array did not invent element names from its contents — it can't, because array elements have no keys. Instead each entry is wrapped in the repeatable <item> tag. Rename that to tag and the editor tags become <tag>admin</tag>, which often reads more naturally.

Attribute mode: the @ convention

Real XML leans heavily on attributes — <user id="42"> is far more idiomatic than burying the id in a child element. Plain JSON has no way to mark "this key is an attribute," so this tool adopts a common convention: turn on Attribute mode, and any key whose name starts with @ is emitted as an attribute on its parent instead of a nested tag. So { "@version": "1.0", "name": "Alice" } produces <root version="1.0"><name>Alice</name></root>. This is the single most useful option for producing XML that downstream parsers expect.

Practical tips

• Pick indentation to match your target. Two spaces is compact and diff-friendly; tabs suit codebases that standardize on them. The indent setting only affects whitespace, never the data.
• Keep the XML declaration on for files, off for snippets. The <?xml version="1.0" encoding="UTF-8"?> header belongs at the top of a standalone document but is noise if you are pasting a fragment into a larger file.
• Name the root for the consuming system. Many APIs require a specific document root (<Envelope>, <feed>). Set it here rather than editing the output afterward.
• Let special characters be escaped for you. The converter automatically turns &, <, >, quotes, and apostrophes into their XML entities, so a value like Tom & Jerry won't break the document.

Common mistakes

• Expecting arrays to become numbered tags. XML has no array type, so a list always becomes repeated identical tags. If you need indices, add them to your JSON as attributes before converting.
• Hyphenated or space-containing keys. "first name" is valid JSON but not a valid tag, so it is sanitized to first_name. Rename keys upstream if the exact tag name matters.
• Forgetting attribute mode is opt-in. A key like @id stays a literal <@id>-style child (sanitized) until you enable attribute mode.
• Pasting invalid JSON. The tool parses with the browser's strict JSON parser, so trailing commas or single quotes will be rejected with an error message rather than silently mangled.

JSON to XML versus the reverse trip

It's worth remembering that this conversion is one-directional and not perfectly reversible. Going from JSON to XML throws away type information — the number 30 and the string "30" both become the text 30 inside a tag, and the boolean true becomes the word true. If you later parse that XML back to JSON, a generic parser has no way to know whether those were numbers, booleans, or strings; everything comes back as text unless you re-apply a schema. So treat the XML as a presentation or interchange format for a consuming system, not as a lossless archive of your original typed data. When you need round-trip fidelity, keep the JSON as the source of truth.

Where your data goes

Nowhere. Parsing and conversion happen locally in JavaScript; the JSON you paste is never uploaded, and the Download button simply saves the generated text from memory. The tool works offline, which is the simplest proof that nothing is transmitted.