Convert JSON into clean, well-structured XML instantly with customizable formatting and conversion options. Everything runs locally in your browser.
JSON
XML
JSON
0 chars
Loading editor…
Paste JSON or upload a .json file to convert it into XML.
Waiting for input
JSON processed locally. Your data never leaves your browser.
Everything happens locally in your browser. Your data is never uploaded.
What is JSON to XML?
Converting JSON to XML means rewriting the same data in a different notation: objects become elements, keys become element names, and values become the text those elements contain.
Both formats describe hierarchical data, which is why the conversion is possible at all. What they do not share is a vocabulary — and that gap is where all the interesting decisions live. XML has no array type. XML element names cannot contain spaces or begin with a digit, while JSON keys can be any string. XML has no null. Every converter has to answer those questions, and the answers are what the options panel exposes.
Note what the XML gained: a declaration, and a <root> wrapper. XML permits exactly one top-level element, so a document has to be wrapped whether or not the JSON had a natural container. Note also what was lost: XML has no types, so true is now the string “true” and 1042is the string “1042”. Recovering them is the reading program’s job, usually via a schema.
Why convert JSON to XML?
Almost always because something on the other side requires it. JSON won the argument for new work; XML is what a great deal of existing, working software speaks, and rewriting it is rarely the cheaper option.
SOAP services. SOAP is XML by definition — the envelope, the header and the body are all elements. A client that thinks in JSON has to convert before it can say anything at all.
Enterprise pipelines. Message buses, ETL tools and B2B exchanges standardised on XML long before JSON arrived, and the schema and transformation tooling around it — XSD, XSLT, XPath — is still more mature.
Systems you cannot change. An application server that reads XML configuration will not learn JSON because you would prefer it. Converting at the boundary keeps the rest of your stack modern.
Documents rather than data. XML is genuinely better at mixed content — text with markup inside it, as in DocBook or XHTML. JSON has no good way to express a paragraph with emphasis in the middle of it.
Attributes carry metadata cleanly. Distinguishing an identifier from the content it labels is something XML expresses natively and JSON does not.
What is not a good reason: file size or parsing speed. XML is larger and slower on both counts. Convert because something needs XML, not because XML is better.
How JSON to XML conversion works
1. The JSON is parsed. Conversion operates on data, not on text, so the document has to be valid first. If it is not, conversion stops and the error is reported with its line and column — producing XML from a document that could not be read would mean inventing the parts that were missing. The JSON formatter is the quicker place to find and fix a syntax error before converting.
2. A root element is opened. XML allows exactly one top-level element, so everything is wrapped in one, named by you.
3. Each value is walked and written. An object writes one child element per key. An array writes its items using the convention you chose. A string, number or boolean writes its text. A null writes an empty element.
4. Names are made legal. Every key is checked against the XML naming rules and corrected if it fails — spaces become underscores, a leading digit gains a prefix. Each correction is listed under the output.
5. Everything is escaped.&, < and > are escaped in text; attribute values additionally escape both quote characters. This is not optional — unescaped, a single ampersand in a value makes the whole document unparseable.
One step is easy to miss and worth stating. JSON strings may contain control characters that XML 1.0 simply cannot represent — and unlike &, there is no escape that rescues them, because a numeric reference to a forbidden character is itself forbidden. They can only be removed. The converter removes them and tells you how many, rather than emitting a document that no parser will accept.
Escaping is what keeps the output parseable
1{ "note": "Tom & Jerry <fast>" }23→ <note>Tom & Jerry <fast></note>
JSON vs XML
They solve overlapping problems and were designed for different ones. JSON is a data format that grew out of a programming language; XML is a document format that grew out of publishing. Most of the differences follow from that.
Types. JSON distinguishes numbers, booleans, strings and null. XML has only text — <n>1</n>is the string “1” until a schema says otherwise. This is the single biggest thing lost in conversion.
Arrays. JSON has them; XML does not. Repetition is expressed by convention — repeated sibling elements, or a wrapper — which is why the conversion needs you to pick one.
Attributes. XML has two places to put a value, an element and an attribute. JSON has one. That extra dimension is expressive, and it is also why two people modelling the same data in XML often disagree.
Size. XML repeats every name twice. Expect the output to be a third to a half larger, before compression.
Mixed content. XML handles text with markup inside it naturally. JSON has no equivalent, which is why documents tend to stay XML.
Comments. XML has them. JSON does not, which is a genuine inconvenience for configuration files.
Tooling.XML has XSD for schemas, XSLT for transformation and XPath for querying, all mature and standardised. JSON’s equivalents exist and are good, but arrived later and are less universally supported.
The practical summary: use JSON where you control both ends, and convert to XML where something on the other side requires it. Neither is going away, and the XML to JSON converter handles the trip back when a response arrives in the other format.
Supported JSON structures
Every JSON type converts. These are the four arrangements you will actually meet, and what each becomes.
Object
The simplest case, and the only one where the two formats agree. Each key becomes an element and each value becomes its content.
JSON
1{2 "id": 1042,3 "name": "Ada"4}
XML
1<root>2 <id>1042</id>3 <name>Ada</name>4</root>
Array
XML has no array type, so a convention has to be chosen. Wrapped keeps the key as a container and names each item inside it.
Scalars behave as you would expect: a string becomes its text, a number and a boolean become their printed form, and a null becomes an empty self-closing element such as <discount/>. That last one is a convention rather than a law — XML has no null — but it preserves the distinction between a field that was absent and one that was present and empty.
XML formatting best practices
Name the root after the thing it contains.<orders> tells a reader more than <root>, and costs nothing.
Match the array convention to the consumer. A WSDL-generated client usually expects repeated elements; a hand-written parser is usually happier with a wrapper. Check before you send, not after it fails.
Use attributes for metadata, elements for content. An identifier, a version or a unit is a good attribute. The thing being described belongs in an element, where it can grow.
Keep the declaration. It is three dozen bytes and it states the encoding explicitly, which removes an entire class of mojibake bug.
Pretty print at rest, compact on the wire. Indentation is for people reading a file, not for the parser at the far end of a socket — the XML formatter switches an existing document between the two.
Never build XML by concatenating strings. The moment a value contains an ampersand or an angle bracket, hand-built markup produces a document that will not parse. Escaping is not optional and is easy to forget.
Validate against a schema if one exists. Well-formed and valid are different claims. This tool guarantees the first; only an XSD can give you the second.
Common use cases
Conversion happens at boundaries — wherever something that speaks JSON has to talk to something that speaks XML.
SOAP APIs
SOAP is XML by definition. A service that speaks it will not accept JSON at all, so anything travelling from a modern client into a SOAP envelope has to be converted first — usually with repeated array elements, which is the convention most WSDL-generated schemas expect.
XML web services
Plenty of long-lived services still publish and accept XML, whether or not they call themselves SOAP. Converting at the boundary keeps the rest of your codebase working in JSON.
Legacy systems
Software written before JSON existed frequently reads XML and nothing else. Conversion is what lets a system built this decade talk to one built two decades ago without rewriting either.
Enterprise integration
Message buses, ETL pipelines and B2B exchanges standardise on XML far more often than on JSON, largely because XML Schema and XSLT arrived long before their JSON equivalents.
Configuration files
Build tools, application servers and CI systems often want XML config. Generating it from JSON keeps the source of truth in a format that is easier to write and to diff.
Data exchange and migration
When two systems disagree about format, one of them converts. Doing it in the browser makes it easy to check the result before committing to a pipeline, which is exactly when mistakes are cheapest to find.
Frequently asked questions
Is this JSON to XML converter free?
Yes. Conversion, every option, the statistics, search, uploads and downloads are all free, with no account, no usage cap and no paid tier. Nothing is held back.
Is my JSON uploaded anywhere?
No. Everything happens inside your browser. The document you paste, drop or open is parsed and converted by JavaScript running on your own machine — it is never sent over the network, stored or logged. You can confirm this by watching your browser's network panel, or by disconnecting from the internet after the page loads: the converter keeps working.
Is the generated XML valid?
Yes, and that is the property the tool is built around. The output is produced by a serialiser rather than by string concatenation: every element name is checked against the XML naming rules, every value is escaped, and characters XML cannot represent are removed rather than emitted. Anything that had to change to make the output parse is reported underneath the result.
Can I convert nested JSON?
Yes, to any depth. Nested objects become nested elements and nested arrays become nested groups, with no limit beyond available memory — the converter is iterative rather than recursive, so a document thousands of levels deep converts without error.
Can I customise the root element?
Yes. XML permits exactly one top-level element, so every document is wrapped in one; the options panel lets you name it. If the name you give is not a valid XML name it is corrected rather than emitted broken, and blank falls back to <root>.
How are arrays converted?
XML has no array type, so there is a genuine choice and the tool offers both conventions. Wrapped keeps the key as a container and names each item — {"users":[a,b]} becomes <users><user/><user/></users>. Repeated drops the container and repeats the key instead — <users>a</users><users>b</users>. Wrapped is easier to read and to write a schema for; repeated is what many older SOAP services expect.
Can JSON keys become XML attributes?
Yes. Pick the keys you want in the options panel and they move from child elements onto the parent element, so {"id":1,"name":"John"} becomes <user id="1"><name>John</name></user>. Only keys that always hold a plain value are offered: an attribute cannot contain an object or an array, so a key that sometimes does would fail on the record where it did.
What happens to null values?
A null becomes an empty, self-closing element such as <discount/>. XML has no null, so this is the closest honest equivalent — it records that the field was present without claiming a value. If you need the distinction preserved for a strict consumer, the usual convention is an xsi:nil attribute, which you would add in a post-processing step.
Why do some of my keys come back renamed?
Because XML element names are far stricter than JSON keys. A key may be any string at all — "user name", "2fa", "@id", even "" — while an XML name cannot contain spaces, cannot begin with a digit and cannot be empty. Invalid characters become underscores and an invalid first character gains one, and every rename is listed under the output so nothing changes silently.
Why is the XML larger than the JSON?
Because XML writes every name twice — once to open the element and once to close it — where JSON writes a key once. Growth of roughly a third to a half is normal, and more for documents with short values and long key names. It compresses well, so the difference over the wire is much smaller than the difference on disk.
Can I download the XML?
Yes. The download button saves the result as data.xml, and the copy button puts it on your clipboard. Both are also on keyboard shortcuts, listed in the options panel.
Does it support large JSON files?
Yes. Documents up to roughly 20 MB are supported. Anything over about 120 KB is parsed in a background Web Worker so the page stays responsive, and the editors only render the lines currently on screen. A megabyte of JSON converts in well under a second.
What happens if my JSON is invalid?
Nothing is converted. Producing XML from a document that does not parse would mean guessing at what was meant, so the tool reports the problem instead: what went wrong, the exact line and column, a plain-language explanation, and a button that jumps the cursor there.
Can I search the generated XML?
Yes. The search bar runs over either the JSON input or the XML output — pick which with the toggle beside it, or press Ctrl+F (Cmd+F on a Mac). Matches are highlighted and counted, and the arrows step through them. Because XML tags, values and attribute text are all plain text in the output, one search covers all three.
Does the converter work offline?
Once the page has loaded, yes. All parsing and conversion is local, so you can disconnect and keep working. A connection is only needed to load the page in the first place.
Keep going
Tools that pair with this one
Same engine, same privacy model — everything below runs in your browser too.
