Convert XML to JSON

The converter walks the XML tree with the browser’s built-in parser and produces one JSON object whose single top-level key is the document’s root element. Each child element becomes a key, and its value is whatever the element contains: a scalar for text-only nodes, or a nested object for elements that have their own children or attributes.

Attributes become keys prefixed with an "@" sign. An element like <price currency="USD"> yields "@currency": "USD". Prefixing keeps attributes in the same object as their element while staying clearly separate from child-element keys, so an attribute and a child that happen to share a name never collide.

When an element carries both attributes and text on the same node, the text is stored under a "#text" key next to the "@" attributes. That is how <price currency="USD">18.5</price> becomes { "@currency": "USD", "#text": 18.5 } rather than losing either half of the information.

Text values are type-coerced on the way in: 184.5 becomes a JSON number and true or false become booleans. Identifiers with leading zeros or very long digit runs are deliberately kept as strings, so an id like 007 or a 20-digit account number survives intact instead of being silently rounded.

XML and JSON do not share a data model, so any conversion has to make choices — and the biggest is single-versus-array. XML has no way to say "this is a list that happens to hold one item." When a tag appears once the converter emits it as a single value — a scalar or an object; the moment a second sibling with the same tag appears, that key becomes an array.

The practical consequence is that the output shape depends on the data, not on a schema. <items><item>2</item></items> makes "item" the single value 2, while adding one more <item> makes "item" an array. If your consuming code iterates, normalize defensively: wrap a lone value in an array before you map over it.

Mixed content — text interleaved with child elements, like <p>See <b>here</b> now</p> — has no clean JSON equivalent. Once an element has child elements the converter keeps only those children and drops the loose text around them, so "See" and "now" would vanish. The "#text" key rescues text only on a leaf element that also carries attributes, not on elements that contain other tags. Document-style XML that blends markup and prose round-trips far worse than record-style data XML.

Attribute-versus-element is a third modeling gap: the same fact can be written as <price currency="USD"> or as <price><currency>USD</currency></price>, and the two produce different JSON. If you control the XML, pick one convention upstream so downstream code does not have to handle both.

A great deal of data still ships as XML: RSS and Atom feeds, sitemaps, SOAP responses, SVG, Office Open XML documents, and plenty of older enterprise APIs. JavaScript speaks JSON natively, so converting first lets you use dot access, destructuring, Array.map, and JSON.stringify instead of manually walking a DOM tree.

A common flow is to fetch a feed, convert a representative sample here to see its shape, then write code against the result — for instance reading rss.channel.item as an array of entries. Seeing the converted structure first removes the guesswork about which tags repeat and which values live in attributes versus text.

For configuration and fixtures, turning an XML file into JSON gives you something you can drop into a test, a JSON config, or a document database. Because the conversion is entirely client-side, you can paste internal or sensitive XML to inspect its shape without it ever leaving your machine.

Once you have the JSON, the full editor is where you actually work with it: format and validate it, expand it as a collapsible tree or a mind map to understand deep nesting, and ask the AI copilot to reshape, filter, or explain the structure before you build against it.

Start with well-formed XML. The browser parser is strict: every tag must close, attribute values must be quoted, and the document needs exactly one root element. Malformed input is reported as a parse error rather than silently repaired, so fix the first error the tool names and convert again.

Escape reserved characters inside text — write & as &amp;, < as &lt;, and > as &gt;, or wrap the text in a CDATA section. An unescaped ampersand is the single most common cause of parse failures in hand-written or string-concatenated XML.

Mind the edges that XML and JSON handle differently. Namespace prefixes are preserved in key names, so <ns:tag> becomes "ns:tag"; comments and processing instructions are discarded. If a value must stay a string — a ZIP code, a version like 1.0, or an id with leading zeros — be aware that plain numeric text is coerced to a number unless it has a leading zero or is very long.

Finally, convert a sample that actually contains the repeating case. Because a lone element becomes an object and repeated siblings become an array, a one-item sample can hide the array shape your production data will produce — so test against data that includes at least two of the repeating element.