JSON and XML, Both Ways
- No Sign-up
- 100% Free
- Zero Server Data
Paste either one and get the other. There is no single correct mapping between the two formats, because XML has attributes, repeated elements and text mixed among children, and JSON has none of those. Every converter picks a convention and most do not tell you, which is how people find that three repeated elements have become one value. Ours is written out below the tool, and there are tests that take a document to the other format and back to prove it comes home unchanged.
Off by default. XML has no types, so 42 is three characters until something decides otherwise. A leading zero is never read as a number.
Paste JSON or XML to convert it.
The rules this conversion follows
Written down so you can rely on them, and tested so they hold in both directions.
<b>text</b>becomes{ "b": "text" }<b id="1">text</b>becomes{ "b": { "@id": "1", "#text": "text" } }<a><c>1</c><c>2</c></a>becomes{ "a": { "c": ["1", "2"] } }<b/>becomes{ "b": "" }Frequently asked questions
Why does the mapping need stating at all?
Because XML can express things JSON cannot. An element can carry attributes and children and loose text all at once, and the same element name can appear three times as siblings. JSON has objects and arrays. Something has to give: here an attribute becomes a key with an @ in front, loose text becomes #text, and a name that appears more than once becomes an array. Knowing that is the difference between a conversion you can automate and one you have to check by hand.
Is my data uploaded?
No. Both conversions run in this tab. The site’s security policy sets connect-src ‘none’, so the browser blocks network requests from these pages, so the document could not be sent even if the code tried. That matters here because the XML people convert is usually an invoice, a tax filing or a system-to-system message.
Why is 42 a string when it comes out of XML?
Because in XML it is three characters and nothing more. A converter that decides it is the number 42 also decides that an order number of 007 is the number 7, and that a price of 1.50 is 1.5. You can turn number reading on with the checkbox; even then, a value that would not survive being written back out is left as text.
Can it read a DOCTYPE?
It skips one, deliberately. A document type definition can declare an entity whose value is the contents of a local file, or one that expands to a billion copies of itself, and those are the two classic ways an XML parser is turned into a weapon. Nothing here resolves an entity it was not born knowing, and an unknown entity is left exactly as it was written rather than dropped.
What happens to comments and namespaces?
Comments are dropped, because JSON has nowhere to put them. A namespace prefix stays part of the element name, so ns:price stays ns:price and comes back the same way. The declaration itself is kept as an ordinary attribute for the same reason.
It refuses my JSON because it has several top-level keys.
XML has exactly one root element, so an object with two keys has no unambiguous XML form. Inventing a root name would make the return trip a lie, so it asks you to wrap it in the one you want instead.