Skip to content
Your data never leaves your browser

XML to JSON Converter

Angle brackets in, curly braces out.

Input
Output

What this does

DEVS: DOMParser (application/xml) to recursive JSON. Attributes go to @attributes, an element's own text to #text when it also has attributes or children. Repeated siblings become arrays. Client-side only.

Paste XML, get JSON. Elements become keys, attributes go under @attributes, and repeated elements turn into arrays. Text that's a plain decimal number becomes a JSON number. Everything else stays a string.

Here's an order with a bit of everything:

<order id="1042" status="paid">
  <customer>Ada</customer>
  <item sku="P-1">pen</item>
  <item sku="P-2">ink</item>
  <zip>02134</zip>
  <total>12.50</total>
</order>

The JSON it produces:

{
  "order": {
    "@attributes": {
      "id": "1042",
      "status": "paid"
    },
    "customer": "Ada",
    "item": [
      {
        "@attributes": {
          "sku": "P-1"
        },
        "#text": "pen"
      },
      {
        "@attributes": {
          "sku": "P-2"
        },
        "#text": "ink"
      }
    ],
    "zip": "02134",
    "total": 12.5
  }
}

The zip code kept its leading zero. 12.50 became the number 12.5. The id attribute stayed the string "1042", because attribute values are never converted. The two <item> elements became an array, and since each has an attribute, its text moved under #text.

Common use cases

Pulling data out of a SOAP response so you can work with it in JavaScript instead of walking a DOM.

Reading RSS feeds, Atom feeds and sitemaps. Paste the feed, see the structure, write the code that reads it.

Moving an old XML config to JSON. The converter gives you a first draft of the new shape. You'll still want to rename the @attributes keys into something your app can live with.

Things to know

Number conversion is strict on purpose. 42, -0.5, .5 and 1e3 become numbers. Leading zeros like 007, hex like 0x1F, a plus sign, 1,000, Infinity and integers bigger than 9007199254740991 stay strings, so IDs and zip codes come through intact. true and false stay strings too. XML text has no booleans, and guessing would be worse.

Mixed content loses its order. When an element holds both text and child elements, its own text goes under #text, trimmed and joined with spaces. <p>Hello <b>world</b> again</p> becomes "#text": "Hello again" plus "b": "world". Fine for data, wrong for documents. Repeated siblings also group into one array even with other elements between them, so the original sibling order is gone.

Comments, processing instructions and the XML declaration are dropped. CDATA comes through as plain text. The five XML entities and numeric references like &#169; decode normally. HTML entities like &nbsp; don't exist in XML, so they're a parse error. Empty elements like <a/> become "".

Privacy

Your browser's own XML parser does the work. The SOAP response with somebody's account number in it stays on your machine. After one visit, it works offline too.

Questions

Why is one child an object, but two children an array?

The converter only sees the document in front of it. One <book> looks like a plain object, two look like a list. If your code expects an array either way, normalize it: Array.isArray(x) ? x : [x]. Any converter that guesses the shape from the document has this problem.

How are XML namespaces handled?

Prefixes stay part of the key, so <soap:Body> becomes "soap:Body". Namespace declarations like xmlns:soap show up as ordinary attributes under @attributes. Nothing gets resolved to a URI, so two files that use different prefixes for the same namespace give you different keys.

What's the difference between @attributes and #text?

@attributes holds an element's attributes, always as strings. #text holds the element's own text, and only appears when the element also has attributes or child elements. A plain <title>Dune</title> is just "title": "Dune".

Can it convert HTML to JSON?

Only HTML that's also well-formed XML. An unclosed <br>, an &nbsp;, or an unquoted attribute value all stop the strict XML parser with an error. XHTML works, as long as it uses numeric references like &#160; instead of &nbsp;.