XML to JSON Conversion: A Developer's Practical Guide

Every few years the developer community gets excited about declaring XML dead. And then you get your first enterprise integration contract, or you pull an RSS feed, or you look at an Android layout file, or someone hands you a SOAP API response the size of a small novel — and there it is. XML. Still very much alive.

This guide isn't about whether XML is good (it has its uses) or bad (it is verbose). It's about the practical problem you face when you have XML data and need JSON, whether to feed it into a modern API, parse it in JavaScript, or just make it readable. Let's get into it.

Why You're Still Seeing XML in 2026

XML was the dominant data exchange format of the late 1990s and 2000s. JSON largely displaced it for web APIs in the 2010s, but XML never disappeared — it just moved into places where it was already entrenched.

Here's where you'll still encounter XML regularly:

RSS and Atom feeds. Every major news site, podcast platform, and blog still publishes an RSS feed in XML. If you're building any kind of content aggregator, news reader, or podcast app, you're dealing with XML.

SOAP web services. Lots of enterprise and government systems use SOAP APIs, which are XML-based. Banking integrations, insurance systems, healthcare APIs (HL7 FHIR has JSON options now, but legacy systems are SOAP), shipping carriers — SOAP is ubiquitous in B2B software.

Maven and Gradle (Java/Kotlin build tools). pom.xml files. If you touch any JVM project, you touch XML. Android's AndroidManifest.xml and layout files are also XML.

Microsoft Office formats. DOCX, XLSX, PPTX are ZIP archives containing XML. Programmatic document generation or parsing often means XML under the hood.

SVG. Scalable Vector Graphics are XML. If you're doing anything with vector images programmatically, you're in XML territory.

Salesforce. Salesforce's SOQL and Bulk API v1 both output XML. Salesforce integration work often involves XML parsing.

Config files. Maven settings, Spring configuration, web.xml, iOS Info.plist (though that's moving to JSON) — lots of configuration in the enterprise world is XML.

The pattern is clear: modern web development skews heavily toward JSON, but the moment you go near enterprise integrations, data feeds, or older ecosystems, XML shows up.

What Makes XML Painful to Work With

If you're used to JSON, XML feels deeply annoying. Here's why.

Verbosity. Compare:

{"user": {"id": 1, "name": "Alice", "active": true}}

versus:

<user>
  <id>1</id>
  <name>Alice</name>
  <active>true</active>
</user>

Both convey the same data. The XML is longer, harder to read at a glance, and more error-prone to write by hand.

Attributes vs. elements ambiguity. XML lets you represent data as either an attribute (<user id="1">) or a child element (<id>1</id>). Both are valid, and different XML schemas make different choices. This inconsistency means you can't predict the structure without reading the schema.

Namespaces. XML namespaces allow element names from different vocabularies to coexist without collision:

<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:media="http://search.yahoo.com/mrss/">
  <media:thumbnail url="https://example.com/img.jpg"/>
</feed>

This is powerful and necessary for complex documents. It's also a headache to parse when you're trying to extract simple values.

Mixed content. XML supports text mixed with child elements:

<p>This is <em>important</em> text.</p>

This doesn't map cleanly to JSON at all. JSON objects are key-value pairs; they can't easily represent "a string with embedded tagged regions."

CDATA sections. XML has a way to embed raw text that shouldn't be parsed as markup. This is useful but yet another edge case to handle.

All of this is why working with XML in JavaScript or Python requires a proper XML library, not string parsing. And it's why converting to JSON — when the structure allows it — makes the data much easier to work with.

How JSON Models Data Differently

JSON has a simpler, more rigid type model:

• Strings — "hello"
• Numbers — 42, 3.14
• Booleans — true, false
• Null — null
• Arrays — [1, 2, 3]
• Objects — {"key": "value"}

Everything in JSON is one of these six types. There's no concept of attributes, no namespaces, no mixed content, no processing instructions, no CDATA. This simplicity is why JSON won for API design — there's only one way to represent data.

XML's data model is much richer. It supports attributes, namespaces, mixed content, comments, processing instructions, and more. This richness is the source of both its power and its verbosity.

When you convert XML to JSON, you're mapping that richer model into the simpler one. Most of the common cases work fine. The edge cases are where things get interesting.

Using the XML to JSON Tool

The XML to JSON converter handles the conversion directly in your browser — no data sent to a server, no installation needed.

Basic usage:

1. Paste your XML into the left panel
2. Click Convert (or it converts automatically)
3. The JSON output appears on the right
4. Copy the JSON and use it wherever you need it

For a simple XML document like:

<?xml version="1.0" encoding="UTF-8"?>
<person>
  <name>Alice</name>
  <age>30</age>
  <email>alice@example.com</email>
</person>

You get clean JSON:

{
  "person": {
    "name": "Alice",
    "age": "30",
    "email": "alice@example.com"
  }
}

Note that age is a string in the JSON output ("30" not 30). XML doesn't have a number type — everything is text. Some converters try to infer types (convert numeric-looking strings to numbers), but this can cause issues with values like phone numbers or IDs that look like numbers but shouldn't be treated as such.

The Attribute Prefix Convention

When an XML element has attributes, they appear in the JSON output with an @ prefix:

<book id="123" lang="en">
  <title>Clean Code</title>
  <author>Robert Martin</author>
</book>

Converts to:

{
  "book": {
    "@id": "123",
    "@lang": "en",
    "title": "Clean Code",
    "author": "Robert Martin"
  }
}

The @ prefix is a widely-used convention (originally from the Badgerfish convention and used in several popular XML-JSON conversion libraries). It distinguishes attributes from child elements in the JSON structure. When you're consuming this JSON in code, you access data.book["@id"] for the attribute value.

Some converters use different conventions — $attr prefix, a separate _attributes object, or flattening attributes as regular keys. The tool uses the @ convention because it's the most widely recognized and interoperable.

Repeated Elements Become Arrays

One of the most important (and potentially surprising) conversion behaviors: when the same tag appears multiple times at the same level, it becomes a JSON array.

<library>
  <book>
    <title>Clean Code</title>
  </book>
  <book>
    <title>The Pragmatic Programmer</title>
  </book>
  <book>
    <title>Refactoring</title>
  </book>
</library>

Converts to:

{
  "library": {
    "book": [
      {"title": "Clean Code"},
      {"title": "The Pragmatic Programmer"},
      {"title": "Refactoring"}
    ]
  }
}

This is correct and useful. But it creates an inconsistency: if the library had only one book, book would be an object, not an array. This trips up a lot of code that assumes the JSON structure is always consistent.

If you're writing code to consume this converted JSON, always handle the case where a field might be either an object or an array. In JavaScript, Array.isArray(data.library.book) before accessing index positions. In TypeScript, type your schema carefully.

When Conversion Isn't Perfect

Some XML features don't translate cleanly to JSON.

Namespaces. The namespace declarations (xmlns="...") may or may not be preserved depending on the converter. Namespace prefixes on element names (media:thumbnail) typically get converted with the prefix included in the key name, like "media:thumbnail". This works, but downstream code needs to know to look for that key.

CDATA sections. <![CDATA[...]]> sections contain raw text that shouldn't be parsed as markup. Most converters extract the text content from CDATA blocks, which is the right behavior. But if the CDATA content contained intentional markup or special characters, verify the output carefully.

Processing instructions. <?xml-stylesheet type="text/xsl" href="style.xsl"?> type declarations are usually dropped by converters. If you need them, you'll have to handle them separately.

XML comments. <!-- comment --> nodes are typically dropped. If your XML uses comments to carry meaningful data (bad practice, but it happens), you'll lose that data in conversion.

Mixed content. The hardest case. <p>Text with <em>emphasis</em> here.</p> doesn't have a clean JSON representation. Converters typically lose the text surrounding the child elements, keeping only the child element values.

For straightforward data exchange — APIs, configuration, data feeds — these edge cases rarely matter. For document-centric XML (content management, technical documentation), you need to be aware of them.

Practical Use Cases

Consuming a SOAP API Response

SOAP response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUserResponse>
      <User id="42">
        <Name>Alice</Name>
        <Email>alice@example.com</Email>
      </User>
    </GetUserResponse>
  </soap:Body>
</soap:Envelope>

Converting this gives you a JSON structure you can work with in JavaScript without a full SOAP library. The namespace prefixes (soap:) appear as part of the key names. For quick data extraction, this is often good enough.

Parsing an RSS Feed

RSS feeds are XML documents with a predictable structure. Converting to JSON makes it much easier to work with in modern JavaScript:

<rss version="2.0">
  <channel>
    <title>Example Blog</title>
    <item>
      <title>First Post</title>
      <link>https://example.com/post1</link>
      <pubDate>Mon, 01 Apr 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Second Post</title>
      <link>https://example.com/post2</link>
      <pubDate>Tue, 02 Apr 2026 00:00:00 GMT</pubDate>
    </item>
  </channel>
</rss>

After conversion, you have a regular JavaScript object where data.rss.channel.item is an array of posts you can iterate over directly.

Reading Android Resource Files

Android strings.xml resource files are XML:

<resources>
  <string name="app_name">My App</string>
  <string name="welcome_message">Welcome back!</string>
  <string name="error_generic">Something went wrong.</string>
</resources>

Converting to JSON makes it easy to process these files in build scripts or tooling without a full Android SDK.

For Programmatic Conversion

If you need to convert XML to JSON repeatedly in code, the quick browser tool isn't the answer. Here are the options:

JavaScript/Node.js: fast-xml-parser is the most widely used library, fast and configurable. xml2js is older but still popular. Both handle attributes, arrays, and namespaces with configurable behavior.

const { XMLParser } = require('fast-xml-parser');
const parser = new XMLParser({ ignoreAttributes: false, attributeNamePrefix: '@' });
const result = parser.parse(xmlString);

Python: xmltodict converts XML to Python dictionaries (which map cleanly to JSON). lxml is more powerful for complex XML processing.

import xmltodict, json
result = xmltodict.parse(xml_string)
json_output = json.dumps(result, indent=2)

Go: encoding/xml is in the standard library, though the API requires struct definitions for clean parsing. github.com/clbanning/mxj provides dynamic conversion similar to xmltodict.

For one-off conversions or debugging, the XML to JSON tool is faster than writing any of this code. For production pipelines, choose a library that fits your language and configure it once.

---

XML isn't going anywhere — the installed base of XML-based systems is enormous and enterprises don't rewrite working infrastructure on a schedule. The practical skill is knowing how to work with it efficiently when it shows up, rather than wrestling with it every time.

Related tools for working with structured data:

• XML Formatter — format, validate, and pretty-print XML
• JSON Formatter — clean up JSON output after conversion
• JSON Diff — compare two JSON structures to spot changes