Convert JSON into well-formed XML in your browser. Choose the root element name, include or omit the XML declaration, and pick 2 spaces, 4 spaces or no indentation.
Map a JSON tree onto elements, safely. Paste JSON and get well-formed XML back. Arrays become repeated elements, invalid key names are coerced into legal element names, and the declaration and indentation are both up to you.
JSON has six value types — object, array, string, number, boolean and null — and every one of them is self-describing. XML has exactly one primitive: text. Everything else is structure built from elements and attributes. There is no official mapping between the two, which is why every converter you meet behaves a little differently.
The convention used here is the most common and the most predictable one. An object becomes an element whose children are its keys. A string, number or boolean becomes an element containing its text form. null becomes an empty element. That leaves arrays, which have no XML counterpart at all: the standard workaround is to repeat the parent element once per item, so {"item": [1, 2]} becomes <item>1</item><item>2</item> rather than inventing a wrapper element the receiving schema will not expect.
XML element names follow the NCName production: they start with a letter or underscore, then allow letters, digits, hyphens, periods and underscores. No spaces, no slashes, no leading digit, and nothing beginning with the letters xml in any casing, which the spec reserves.
JSON keys have no such restriction — they are arbitrary strings, and real-world payloads are full of "user name", "2024" and "@type". Emitting those verbatim produces a document no parser will accept. Invalid characters are therefore replaced with underscores and a leading underscore is added when a name starts with a digit. It is a lossy step, so if the element names matter downstream, rename the keys in the JSON first rather than letting the converter guess.
The <?xml ... ?> declaration is optional for UTF-8 documents; parsers assume UTF-8 when it is absent. Include it when the file will be written to disk, served over HTTP or handed to a strict enterprise pipeline, and leave it out when the fragment is being embedded inside a larger document, where a second declaration is a fatal error.
Indentation is the subtler choice. Unlike JSON, XML whitespace inside an element is part of the content, so pretty-printing technically changes the document: an element that held Ada now holds a newline, some spaces, Ada, a newline and more spaces. Most schemas ignore this, but signature verification, xml:space="preserve" sections and whitespace-sensitive formats do not. Use indentation while you are reading, and switch to minified output for anything a machine will consume.