Convert JSON to XML

Drop a JSON file here

or paste it below — .json, .ndjson, .txt

JSON

Root element

Name for list entries

Attribute keys

Indentation

XML declaration the <?xml version="1.0"?> first line Write nulls as xsi:nil="true" instead of an empty element Record the original key when one had to be renamed adds original-name, so the rename is reversible

Paste JSON or drop a file in and get well-formed XML back. JSON allows key names that XML forbids - spaces, punctuation, a leading digit - so every converter quietly cleans them up, and cleaning up is where data goes missing: two different keys can end up as the same tag and become impossible to tell apart. This one renames what it has to, lists every rename, and warns you when a rename made two fields indistinguishable. Nothing is uploaded.

Nothing is uploaded — the file stays on your device
No file size limit
No sign-up, no watermark
Free, with no paid tier holding anything back

How to convert JSON to XML

Drop a .json file into the box above or paste the JSON straight in. Newline-delimited JSON works too — one object per line.
Set the root element name, and the name used for entries when a list has to become repeated elements.
Keys starting with @ become attributes. Leave that on if your JSON came from our XML to JSON page and you want the attributes back where they started.
Press Convert to XML and read the report. Renames and collisions are the part worth looking at.

JSON keys and XML names do not overlap

A JSON key can be any string at all. An XML element name cannot: it has to start with a letter or an underscore, it cannot contain spaces or most punctuation, and it is not allowed to begin with the letters xml in any casing. So a converter has to rename, and every converter does:

JSON key	Why it is illegal	Becomes
`"user name"`	Space	`user_name`
`"123id"`	Starts with a digit	`_123id`
`"pr!ce"`	Punctuation	`pr_ce`
`"xmlThing"`	Reserved prefix	`_xmlThing`

That much is unavoidable. What is avoidable is doing it in silence, because renaming is not always a cosmetic change.

The rename that costs you a field

Consider a record with both "user name" and "user_name" — two separate fields, which happens constantly in data assembled from more than one source. Both are legal JSON. Both become <user_name>. The output is well-formed XML in which the two values are no longer distinguishable from one another, and nothing about the file says so.

This page detects that case and reports it as a problem, naming both keys. It is usually a five-second fix at the source, and it is only findable while you still know the conversion happened. There is also an option to write the original key into an original-name attribute on any element that had to be renamed, which makes the whole mapping reversible rather than just documented.

The character that makes a file unreadable

JSON strings may contain escaped control characters — \u0001 and friends. XML 1.0 cannot represent them at all: not literally, not as a numeric reference, not inside CDATA. There is no escape that works.

A converter that copies the character through produces a file that fails to parse in every conformant reader, and the failure surfaces somewhere else, later, as somebody else's error message. Here those characters are removed and counted, so the output is a file that actually opens and you know one byte of input did not survive.

What each JSON type becomes

JSON	XML	Note
Object	Element with child elements	Keys become tag names
Array	The element repeated	A one-entry list is indistinguishable from a plain value
String, number, boolean	Element text	XML has no types; a schema supplies them
`null`	Empty element	Or `xsi:nil="true"` if you switch it on
`"@id"`	An attribute	Round-trips with our XML to JSON page
`"#text"`	The element's own text	Lets you rebuild mixed content

Numbers come out better here than in the other direction

Going from XML to JSON, long identifiers are a hazard: JavaScript cannot hold a whole number past 9,007,199,254,740,991 exactly, so converting one changes its final digits. Going this way the risk is smaller, because XML has no number type — everything is text. A large value that is already a JSON number has been through that narrowing before it reached this page, though, so if your IDs matter, keep them as strings in the JSON rather than as numbers.

Next steps

XML to JSON goes back the other way and keeps repeating elements as arrays so the shape does not drift between files. XML to CSV turns a record-shaped XML document into rows, and JSON to CSV does the same from JSON. All of them are listed on the data tools page.

Frequently asked questions

What happens to a JSON key that is not a legal XML name?

It is renamed, because there is no alternative - XML element names cannot start with a digit, cannot contain spaces or most punctuation, and cannot begin with the letters xml in any casing. Illegal characters become underscores and a leading digit gets an underscore in front of it. The difference here is that every rename is listed on the page instead of happening quietly, so the mapping between your JSON and the XML you hand to someone else is written down.

Two of my keys turned into the same tag. Why does that matter?

Because it is data loss rather than a formatting change. The keys "user name" and "user_name" are different fields in JSON and both become user_name in XML, so nothing downstream can tell which value came from which. Every other converter we checked does this silently. This one raises it as a problem and names the keys involved, which is usually enough to rename one at the source before the file goes anywhere.

Can I produce attributes instead of child elements?

Yes. A key beginning with @ becomes an attribute, so "@id": 7 emits id="7" on the element rather than a child. That is the same convention our XML to JSON page uses, so a round trip through both pages puts attributes back where they started. You can change the prefix if your JSON already uses a different one.

What happens to arrays?

XML has no array type, so a list becomes a repeated element: three entries under "tags" emit three tags elements side by side. This is lossy in one specific way worth knowing about - a list with a single entry emits one element, which looks exactly like a plain value to whatever reads it next. If the reader cares, an XML Schema is what tells it the element is a list.

My JSON has a control character in a string. What do you do with it?

It is removed and counted. JSON permits escaped control characters such as \u0001, XML 1.0 has no way to represent them at all, not even as an entity, and a file containing one fails to parse in every conformant reader. Most converters copy the character straight through, so the output is invalid and you find out much later, from somebody else's error message.

How are null values written?

As an empty element by default, which is the common convention. You can switch on xsi:nil="true" instead when the consumer distinguishes an empty string from a missing value - some schemas do, and the difference between the two is a real one.

Does the output have an XML declaration?

Yes, version 1.0 with UTF-8, and you can turn it off for fragments that will be embedded in a larger document. The output is genuinely UTF-8, and the characters that XML treats specially in text and attribute values are escaped, so the file reads back identically.

Is my file uploaded?

No. The JSON is parsed and the XML is written inside your browser tab, so payloads, exports and API responses never travel to a server. There is no size limit beyond your own device's memory.