JSON to XML Converter

How JSON maps back to XML
Going from JSON to XML means inventing information that JSON does not carry. JSON has no concept of an attribute, no single root requirement and no distinction between an element and a value — XML needs all three. This converter resolves that with one simple rule: object keys become elements, keys prefixed with @ become attributes, and a #textkey becomes the element's text content. That is the inverse of the convention our XML to JSON converter produces, so a document can make the round trip and come back equivalent.

{
  "book": {
    "@id": "1",
    "title": "XML Guide",
    "tags": { "tag": ["computer", "reference"] }
  }
}

<?xml version="1.0" encoding="UTF-8"?>
<book id="1">
  <title>XML Guide</title>
  <tags>
    <tag>computer</tag>
    <tag>reference</tag>
  </tags>
</book>

Choosing the root element
An XML document must have exactly one outermost element, but JSON has no such rule — an object can have twenty top-level keys, and the whole document can even be an array or a bare number. So when your JSON has a single top-level key, that key becomes the root element, which is almost always what you want. In every other case — several top-level keys, a top-level array, or a lone value — the content is wrapped in a <root> element so the result is still valid XML. A single key whose value is an array is wrapped too, because using it as the root would produce several sibling roots and therefore an invalid document.

How arrays become repeated elements
XML expresses a list by repeating a tag, so a JSON array becomes one sibling element per item, all sharing the key's name: "tag": ["a", "b"] becomes <tag>a</tag><tag>b</tag>. Note that this is a one-way simplification — the resulting XML no longer records that those elements were a list rather than two coincidentally identical siblings, which is the same ambiguity that makes the reverse direction tricky. A bare array with no key to repeat (a top-level array, or an array nested directly inside another array) uses <item> for its entries.

Which JSON keys cannot be XML names
JSON keys are arbitrary strings; XML element names are not. A name must start with a letter, underscore or colon, and may then contain only letters, digits, hyphens, periods, underscores and colons. So {"1st": …}, {"my key": …} and {"$price": …} have no valid XML equivalent. Rather than silently mangling them into something that looks fine but is not the data you gave it, this tool stops and names the offending key so you can rename it — a converter that quietly strips the space or drops the digit is doing you no favours.

How to use this tool:
1. Paste your JSON into the left pane, or click "Load sample" for a worked example.
2. Pick your indentation — 2 spaces, 4 spaces, Tab, or Minified for a single line.
3. Click "Convert". Invalid JSON is reported with the parser's message, and a key that cannot become an XML name is reported with the key named and the caret pointing at it.
4. Use "Copy" or "Download" in the toolbar to take the XML away as text or as a converted.xml file.

Escaping is handled for you
Five characters cannot appear literally in XML, and forgetting them is the number one cause of documents that will not parse. Text content has &, < and > escaped; attribute values additionally have " escaped, and tabs and newlines converted to numeric references so parsers do not normalise them away. That means a value like Tom & Jerry is emitted safely rather than producing XML that breaks the moment anything reads it. The output is always a well-formed document that our XML validator accepts.

Privacy & Security Guarantee
The JSON parser and the XML writer both run in your browser as client-side JavaScript — there is no upload and no server-side processing, so API payloads, config files and customer records never leave your computer. Working the other way, or just tidying up? See the XML to JSON Converter and the JSON Formatter & Validator.