JSON to XML Converter

Name the item tag — it is the difference between usable and machine-generated

The setting worth changing, and almost no other converter offers it.

JSON arrays have no names for their members. An XML list needs one, so every converter invents a tag, and the usual choice is <item>. That gives you output like <orders><item>…</item><item>…</item></orders>, which is valid and reads like something a machine produced under protest.

Set the item tag to order instead and you get <orders><order>…</order></orders> — which is how anyone would write that XML by hand, and what a schema is far more likely to expect. Set it to product, row, entry, record: whatever the singular of your list is.

It is one field and it removes an entire post-processing step. The root element name works the same way — root is the default, and orders, response or catalogue is usually what you actually want.

Some of your keys will be renamed, and you need to know which

The thing that catches people, because it happens silently and the output is still valid XML.

JSON object keys can be almost anything — spaces, punctuation, starting with a digit, starting with a symbol. XML tag names cannot. A tag cannot contain a space, and it cannot begin with a number.

So keys get adjusted to fit. "first name" becomes <first_name>. "2024" becomes <_2024>, with an underscore added because a tag starting with a digit is not legal. "total (USD)" becomes <total__USD_>. Anything outside letters, digits, underscore, dot and hyphen turns into an underscore.

That is the right behaviour — the alternative is XML that no parser will accept — but it means the output tag may not match the key you started with. If something downstream is looking for a specific element name, check the result rather than assuming. Keys with spaces, units in brackets, or years and IDs as keys are the ones to look at.

If you control the JSON, the cleaner fix is to rename those keys before converting.

Everything becomes an element — there are no attributes

The most important limitation, and it decides whether this tool fits your job.

XML can carry information in two places: inside elements and in attributes. JSON has only one kind of thing, so a converter has to pick, and this one puts everything into elements.

Practically: if the system you are feeding expects <order id="42">, what you will get is <order><id>42</id></order>. Both contain the same information and they are structurally different documents. A parser reading by XPath, or validating against a schema that declares id as an attribute, will reject the second.

So this is the right tool when the receiving end is flexible about structure, or when you define the schema yourself, or when the XML is going somewhere that just needs the data present. It is the wrong tool when you must match an existing schema that uses attributes — for that you need a proper mapping, not a generic conversion.

The round trip does not come back the same

Worth saying plainly, because it is a reasonable thing to assume and it is not true.

Converting XML to JSON and back does not return your original document. Going to JSON, attributes are gathered under a special key, comments are dropped, and the order of differently named siblings is lost because a JSON object does not preserve it. Coming back here, that special key becomes an ordinary element with an underscore in its name — so your attributes arrive as a nested element called _attributes rather than as attributes.

JSON and XML are genuinely different shapes, and converting between them is a translation rather than a transformation. Fine in one direction for a specific purpose; not a way to store XML as JSON and get it back.

The smaller settings

Indentation — two spaces by default, four if that matches your codebase, tab, or minified. Minified is for XML being sent over a wire rather than read; anything a person will look at wants indentation.

XML declaration — the <?xml version="1.0"?> line, included by default. Turn it off when the output is going to be embedded inside a larger XML document, because a declaration is only legal at the very start of a file.

Values are escaped properly on the way out, so an ampersand, an angle bracket or a quotation mark in your data becomes the correct entity rather than breaking the document. A null becomes an empty element.

Invalid JSON is reported with the parser's own message, which usually names the position of the problem — far more useful than a generic failure.

One thing not to be alarmed by: the preview box on the page shows the first few thousand characters only. The downloaded file is complete — the preview is capped so a large conversion does not lock up the page.

Nothing leaves your browser

The conversion uses no external library and makes no network request. That matters given what JSON files usually are: API responses with real records in them, configuration including endpoints and keys, database exports, order and customer data. Pasting one into a web converter hands the whole file to whoever runs it.

Related tools

XML to JSON Converter goes the other way, and explains the problem in that direction — one element becomes an object, two become an array. JSON to CSV Converter flattens JSON into a spreadsheet instead, and CSV to JSON Converter is the route in from a CSV.