XML to JSON

How it works

Paste the XML into the left pane and the JSON appears in the right one as you type. Four rules govern the conversion. Attributes enter the object with an @ in front of their name, which keeps them from colliding with a child element that happens to have the same name. An element holding nothing but text collapses to that text; if it also has attributes or children, the text is filed under a '#text' key instead. Sibling elements repeating under the same parent are gathered into one array, in document order. CDATA content is taken literally, while comments and the <?xml?> declaration are skipped. When the document is not well formed you get no output but a message naming the tag and the line where the parser stopped, and an unclosed tag, a mismatched closing tag and an unquoted attribute value are reported as separate cases. The result can be copied in a single click or downloaded as a .json file, and none of it leaves your device.

This tool is also known as xml to json, xml to json converter, convert xml to json, xml parser online, xml to json online.

What is XML?

XML (Extensible Markup Language) marks data up with nested tags: every piece of content sits between an opening and a closing tag, and extra detail is attached to a tag as attributes. It resembles HTML, but the set of tag names is not fixed — whoever defines the data chooses them. A great deal of institutional software still runs on it: SOAP web services, RSS feeds, sitemaps, the insides of Office documents, invoicing and banking formats, and countless configuration files. To count as well formed, a document needs exactly one root element, a closing tag for every opening tag, and quotation marks around every attribute value.

What is CDATA?

A CDATA section tells the parser to treat everything inside it as literal text, and it is written between <![CDATA[ and ]]>. Normally a < or & inside content is read as the start of a tag or an entity and breaks the document; avoiding that means either escaping every mark as &lt; and &amp; or wrapping the whole passage in CDATA. Fields holding source code, an HTML fragment or free-form text full of punctuation are far more readable that way. This tool takes CDATA content exactly as it stands and never touches the characters inside it.

What is the difference between XML and JSON?

Both carry data as text, but they answer different questions. XML is a markup language: it wraps content in tags, hangs attributes off those tags, allows structure inside running text, and can state formally through a schema which fields a document must contain — which is worth having where a document has legal weight, as in invoicing or banking formats. JSON is a notation for data structures: objects, arrays, numbers, strings and booleans, with no notion of an attribute and less text around the same content. Web services moved to JSON for that plainness, since nearly every language parses it in a single call. The difficulty of converting comes straight from the asymmetry: attributes and repeated tags have no direct equivalent in JSON, which is why rules like the @ prefix and array gathering have to be invented.

The conversion rules

The data models of XML and JSON do not line up one to one, so every converter has to declare its own rules and stick to them. These are the rules applied here:

• Attribute → an '@name' key: <item code="SKU-11"> yields a '@code' field
• Element with text only → a plain string: <customer>Ada</customer> becomes 'Ada'
• Text plus attributes or children → the text moves under a '#text' key
• Repeated sibling elements of the same name → an array, in document order
• Empty element (<note/>) → an empty string
• CDATA is taken as it stands; comments and the <?xml?> declaration are dropped

Single element or array: the trap to know about

The decision is made by counting. An element that appears twice becomes an array; an element that appears once becomes an object. XML itself has no way of saying "this position is always a list" — that belongs in a schema (XSD), and no schema is read here.

The practical consequence is that two documents of the same design can produce different JSON. An order with one item gives you an object, the same order with two items gives you an array. If code is going to consume the output, test whether the field is an array before you iterate over it. This is the single most common bug in systems moving from XML to JSON.

Scope limits: namespaces, DTD and entities

The parser is small, hand-written and runs inside your browser. Its scope is deliberately narrow, and the boundaries are stated here rather than left to be discovered halfway through a job:

• Namespaces are not resolved: 'ns:tag' keeps its prefix as part of the key, and xmlns attributes are treated as ordinary attributes
• DTD and <!DOCTYPE> declarations are skipped, so custom entities defined there are not expanded
• Only &amp; &lt; &gt; &quot; &apos; and numeric references in &#NNN; or &#xNN; form are resolved; an unknown entity is left in the text exactly as written
• No schema (XSD) validation is performed — the document is only checked for being well formed

Why entity expansion is switched off

Entities defined inside a DTD are allowed to refer to one another. Ten lines of such definitions can expand into gigabytes of text; this is the classic resource-exhaustion trick known as the entity bomb, or the billion laughs attack. A parser that expands entities freely will lock up the tab trying to process a document like that.

Because this conversion runs on your own machine, the cost of that would land on you. Entity handling is therefore limited to the five predefined shortcuts and numeric references, and nothing that reads an external resource or expands recursively is processed at all.

Frequently asked questions

Why do attributes start with @?

Because an element can carry an attribute named 'code' and a child element named 'code' at the same time, and in JSON both would land on the same key with one of them silently lost. Prefixing attribute names with @ prevents that collision, and it is the widely used convention for this conversion.

Why does the same document shape produce a different structure?

The structure follows the data: an element occurring once becomes an object, one occurring twice or more becomes an array. If you need lists to be arrays every time, check for an array on the consuming side before reading the field.

Do namespace-prefixed tags (ns:tag) work?

They are read and converted, but the namespace is not resolved: the prefix stays part of the key, so 'ns:tag' is 'ns:tag' in the JSON too. xmlns attributes are not removed either; they appear as '@xmlns' fields.

Is the XML I paste sent anywhere?

No. Parsing and conversion happen entirely inside your browser, so an invoice, an order or a configuration file stays on this page and never reaches a server.