ToolSite

How to Convert XML to JSON and Why You Would

Convert XML to JSON for legacy API migration, frontend apps, and data pipelines. Handle attributes, namespaces, and arrays with our free XML to JSON converter.

By ToolSite4 min readguides

XML Is Still Everywhere

XML was the dominant data interchange format for enterprise software through the 2000s and early 2010s. Many systems still expose SOAP APIs, RSS feeds, and configuration in XML. But modern frontends and microservices consume JSON.

The bridge is XML-to-JSON conversion. You take an XML document, parse it, and output equivalent JSON that a browser, mobile app, or Node.js service can consume directly. The conversion is mostly mechanical but has several edge cases you need to handle.

The Basic Conversion

A simple XML document:

<person>
  <name>Alice</name>
  <email>alice@example.com</email>
  <active>true</active>
</person>

Converts to:

{
  "person": {
    "name": "Alice",
    "email": "alice@example.com",
    "active": "true"
  }
}

Elements become keys. Text content becomes string values. The root element becomes the top-level key. This works cleanly for documents with no attributes, no repeated elements, and no namespaces.

Attributes: The XML Feature JSON Doesn't Have

XML has attributes. JSON has no concept of attributes, only key-value pairs. Converters handle this by prefixing attributes with @ or nesting them under a dedicated key:

<person id="42" role="admin">
  <name>Alice</name>
</person>

Common JSON representations:

{
  "person": {
    "@id": "42",
    "@role": "admin",
    "name": "Alice"
  }
}

Some converters use a - prefix, a $ prefix, or a separate _attributes object. Check your converter's convention before building application logic around it. The @ prefix is the most common convention, used by libraries like xml2js in Node.js and Python's xmltodict.

Array Handling: The Single-Child Problem

XML has no array type. A repeated element could be a list or a single value:

<users>
  <user>Alice</user>
  <user>Bob</user>
</users>

This is clearly an array. But what about:

<users>
  <user>Alice</user>
</users>

Is <users> an object with a single user property, or an array with one element? A good converter infers arrays from the schema (if available) or from the XML structure. Without schema hints, a single child element may be treated as an object, not an array, which breaks downstream code that expects an array.

When converting, always check whether repeated elements made it into the JSON as arrays. If a field that should be ["Alice", "Bob"] appears as "Alice", the converter missed the array inference. Some converters let you pass a list of element names that should always be treated as arrays to solve this.

Mixed Content

XML allows mixed content: text and child elements inside the same parent:

<description>Alice is a <role>developer</role> at Acme Corp.</description>

JSON has no direct equivalent. Converters typically produce something like:

{
  "description": {
    "#text": "Alice is a ",
    "role": "developer",
    "#text2": " at Acme Corp."
  }
}

Mixed content is rare in data-oriented XML but common in document-oriented XML like XHTML. If your XML has mixed content, expect the JSON output to be awkward. Consider whether you can restructure the XML to separate markup from text before converting.

Namespaces

XML namespaces add another layer:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Example Feed</title>
</feed>

A converter might strip the namespace, prepend it to keys (atom:title), or keep it as metadata. Decide based on whether the JSON consumer needs namespace information. For most API migrations, stripping namespaces is fine because the JSON consumer doesn't care about the XML namespace. For round-trip scenarios, keeping namespace prefixes preserves fidelity.

When to Convert

  • Legacy API migration: you're replacing a SOAP backend with REST and need to bridge the old XML responses to new JSON consumers. Write an adapter layer that converts XML to JSON at the boundary.
  • RSS/Atom feeds: parsing feed data into a JSON-friendly format for a frontend widget. Most RSS readers expect XML, but your React component expects JSON.
  • Configuration migration: moving from XML-based config (Maven pom.xml, old .NET app.config) to JSON or YAML.
  • Data pipeline: an upstream system produces XML and a downstream system expects JSON. A conversion step in your ETL pipeline bridges the gap.
  • Web scraping: many sitemaps and APIs still return XML. Converting to JSON makes the data easier to work with in Python or JavaScript.

The Round-Trip Problem

Converting XML to JSON is not lossless. Attributes, namespaces, processing instructions, and CDATA sections may not survive the round-trip back to XML. If you need perfect fidelity, keep the XML source and treat the JSON as a read-only view, not a replacement.

CDATA sections (<![CDATA[...]]>) are particularly tricky. They exist to escape characters that would otherwise be parsed as XML, but JSON has no CDATA concept. Most converters inline the CDATA content as a plain string, which works for reading but can't be reconstructed perfectly.

Try it yourself: open the XML to JSON Converter. Paste <person id="42"><name>Alice</name></person> and click Convert. See how the id attribute becomes @id in the JSON output. Then try an XML document with repeated <item> elements and confirm the converter produces arrays.

Related Reading