Skip to the JSON editor
JSON Formatter Viewer

XML to JSON

input.xml

output.json

The JSON appears here.

or drop a .xml file into the left pane

Waiting for input

The mapping

<book id="b1">
  <title>Dune</title>
  <tag>scifi</tag>
  <tag>classic</tag>
</book>

{
  "book": {
    "@id": "b1",
    "title": "Dune",
    "tag": ["scifi", "classic"]
  }
}
  • Attributes become @-prefixed keys.
  • A repeated child tag collapses into an array on its second occurrence.
  • An element with only text becomes that text directly.
  • An element with both attributes and text keeps the text under #text.
  • Text that looks like a number, true, or false is converted, since XML carries no type information of its own.

The one ambiguity worth knowing

XML cannot distinguish a list of one from a single value. A document with three<tag> elements produces an array; the same document with one produces a plain value. Only a schema resolves this, so code consuming the output should tolerate both — or normalise once, right after parsing.

Why the browser's parser

Hand-written XML parsers get entities, CDATA, and encoding declarations wrong in ways that only show up on real documents. DOMParser is the same engine that parses XML everywhere else in the browser, so behaviour here matches what the rest of the platform does — and malformed input is reported as a parse error with the reason rather than being quietly mangled.

After converting

Open the result in the tree viewer to explore a deep document, or useJSON to XML to go back.

Common questions

Why is a single child not an array when the same tag repeats elsewhere?

Repetition is what signals a list, and a document with one <item> looks identical to one with a single value. Only an XML Schema knows which tags are collections, so without one this ambiguity is unavoidable. Check for both shapes in code that consumes the result.

How are attributes represented?

As keys prefixed with @, so <book id="b1"/> becomes {"book": {"@id": "b1"}}. An element with both attributes and text puts the text under #text. JSON to XML reads the same convention back.

Are CDATA sections and entities handled?

Yes. Parsing uses the browser's own XML engine, so &amp;, numeric character references, CDATA blocks, and the encoding declaration are all resolved by the same implementation that handles them everywhere else in the browser.

What happens to namespaces?

Prefixed names are kept verbatim as keys — <ns:title> becomes "ns:title" — and xmlns declarations appear as ordinary @xmlns attributes. Nothing is silently stripped.

The rest of the toolkit

Same engine, same privacy — every page runs entirely in your browser.