XML to JSON Converter
Paste XML on the left — clean, structured JSON appears on the right, with attributes, repeated elements and CDATA all handled. Nothing leaves your browser.
How XML to JSON Conversion Works
XML and JSON describe the same trees of data in different syntax, so conversion is a matter of mapping rules rather than translation. This converter parses your document into a tree of elements first — which is also what validates it — then walks the tree applying three rules. A tag becomes a key. An element holding only text becomes a string under that key. And structure is preserved exactly: nested elements become nested objects, and repeated sibling tags become an array, because JSON has no other way to hold two values under one name.
Two design decisions are worth knowing before you rely on the output. Attributes move under an @attributes key, separated from child elements so an attribute named "id" can never clash with a child element also named "id". And every value stays a string. XML has no native numbers or booleans, so converting "3" into 3 would be a guess — one that destroys leading zeros in codes like "007" and turns phone numbers into arithmetic. Faithful first; your code can parse numbers where it truly needs them.
Worked Example: An Invoice, Converted
Feed in the sample invoice above — two line items, each carrying a sku attribute — and the converter returns this (abbreviated layout, exact content):
{
"invoice": {
"number": "INV-2041",
"customer": "Northwind Traders",
"item": [
{
"@attributes": { "sku": "A-100" },
"name": "Widget",
"qty": "3",
"price": "9.99"
},
{
"@attributes": { "sku": "B-220" },
"name": "Gadget",
"qty": "1",
"price": "24.50"
}
],
"total": "54.47"
}
}
Three things to notice. The two <item> elements became an array of two objects, in order, because the tag repeats. Each sku attribute sits under @attributes, distinct from the child elements around it. And the figures stayed strings — "54.47" included — even though the invoice's own arithmetic checks out: 3 × 9.99 + 24.50 = 54.47. If the input had a mismatched tag, say a </custmer> typo, the tool would stop and point at the problem instead of emitting JSON built on a guess. Working the other direction — formatting and validating JSON itself — is the JSON Formatter's job.
Where This Conversion Earns Its Keep
The usual trigger is a feed or API that speaks XML to a codebase that speaks JSON: supplier catalogues, shipping and invoicing exports, RSS and sitemap files, legacy SOAP responses, configuration formats. Converting at the boundary means the rest of your stack only ever handles one data format. Because this page runs entirely in your browser, it is also the safe option for XML containing order details or customer data that should not be pasted into a server-side tool.
Frequently Asked Questions
How does this XML to JSON converter map elements and attributes?
Each element becomes a key named after its tag. An element that only holds text converts to a plain string. Attributes are collected under an "@attributes" object so they can never collide with child elements, and when the same tag appears more than once under one parent, those values are gathered into an array, in document order. An element that has both attributes (or children) and text keeps its text under "#text".
Why are the numbers in my JSON shown as strings?
Because XML itself has no number type — everything in an XML document is text, so "qty": "3" is the faithful conversion. Most programming languages make it a one-line step to parse those strings into numbers where you need them (parseInt or Number() in JavaScript). Guessing types during conversion would corrupt values like phone numbers, leading zeros and product codes, so this converter never guesses.
What happens if my XML is invalid?
You get a plain-language error instead of broken JSON — the converter reports problems like a mismatched closing tag (and roughly where in the document it happened) so you can fix the source. XML is strict by design: every opened tag must close, attributes must be quoted, and there must be exactly one root element.
Can it handle large XML files?
Yes, within reason. The document is parsed by code running in your browser tab, so files of a few megabytes convert comfortably. Extremely large exports (tens of megabytes) will be slow in any browser tool — for those, split the file or use a desktop converter. Nothing is uploaded, so there is no server-side file size limit to hit.
Does it support CDATA sections and entities?
Yes. CDATA sections are read as literal text (markup characters inside them are not treated as tags), and the standard entities — &, <, >, ", ' and numeric character references — are decoded into the characters they stand for, so 'Tom & Jerry' becomes 'Tom & Jerry' in the JSON.
Is my XML uploaded to a server?
No. The conversion runs entirely in your browser using code on this page — your document is never uploaded, stored or logged. That makes it safe for configuration files, order exports and other XML you would not paste into a stranger's server.