How to Convert XML to JSON (Methods & Best Practices)

XML and JSON are the two most widely used formats for structured data, and at some point, you will need to convert between them. Maybe you’re migrating a SOAP API to REST. Maybe you’re feeding an XML data export into a JavaScript application. Maybe you just need to read a complex XML document more easily in a format your brain already parses quickly.

Whatever the reason, XML-to-JSON conversion isn’t a simple find-and-replace. The two formats represent data differently at a fundamental level, and the mapping decisions you make affect whether the output is usable or a mess. The XML to JSON Converter handles the conversion in your browser with sensible defaults, but understanding what happens under the hood helps you handle the edge cases that every real-world dataset throws at you.

Why Convert XML to JSON?

Before digging into the mechanics, here are the most common scenarios that drive conversion.

API Migration

Legacy SOAP and XML-RPC services return responses in XML. When rebuilding these as REST APIs, the natural response format is JSON. Converting existing XML payloads to JSON is often the first step in understanding the data structures before designing the new API schema.

Data Processing Pipelines

ETL (Extract, Transform, Load) workflows frequently receive XML feeds from enterprise systems — financial reports, healthcare records, government data exports. Downstream tools like Elasticsearch, MongoDB, and most modern analytics platforms work natively with JSON. Converting XML to JSON at the ingestion point simplifies every subsequent step.

Frontend Development

Frontend applications work with JSON natively. While XML can be parsed, working with the resulting tree structure is verbose compared to accessing JSON properties directly. Converting XML feeds to JSON before loading them into a web app makes the code cleaner and less error-prone.

Quick Inspection and Debugging

Deeply nested XML with attributes, namespaces, and mixed content can be hard to scan visually. Converting to JSON and viewing it in a formatter with collapsible sections makes the structure immediately apparent. The XML to JSON Converter paired with the JSON Formatter is a fast way to inspect unfamiliar XML documents.

How the Conversion Maps XML to JSON

XML and JSON have different structural primitives. XML uses tags, attributes, text content, and a strict ordering of elements. JSON uses objects (key-value pairs), arrays, strings, numbers, booleans, and null. The conversion must map each XML concept to its closest JSON equivalent.

Elements Become Object Keys

Each XML element becomes a key in a JSON object. The key name is the tag name, and the value depends on the element’s content.

XML:

<person>
  <name>Alice</name>
  <age>30</age>
</person>

JSON:

{
  "person": {
    "name": "Alice",
    "age": "30"
  }
}

Note that "age" is a string "30", not a number 30. XML has no type system — everything is text. The converter preserves this as a string. If you need typed values, you must handle the parsing in your application code.

Attributes Use the @ Prefix

XML attributes have no direct equivalent in JSON. The most widely adopted convention is to prefix attribute names with @.

XML:

<book category="fiction" isbn="978-0-13-468599-1">
  <title>The Great Gatsby</title>
</book>

JSON:

{
  "book": {
    "@category": "fiction",
    "@isbn": "978-0-13-468599-1",
    "title": "The Great Gatsby"
  }
}

This convention is used by most major XML-to-JSON conversion tools across different programming languages. Some converters use _ or - as the prefix instead. The XML to JSON Converter uses the @ convention.

Repeated Elements Become Arrays

XML has no explicit array type. If a parent contains multiple children with the same tag name, they’re implicitly a list. JSON makes this explicit by grouping them into an array.

XML:

<colors>
  <color>Red</color>
  <color>Green</color>
  <color>Blue</color>
</colors>

JSON:

{
  "colors": {
    "color": ["Red", "Green", "Blue"]
  }
}

But here’s a common gotcha: if there is only one <color> element, most converters produce a plain string instead of a one-element array:

{
  "colors": {
    "color": "Red"
  }
}

This inconsistency is the single biggest source of bugs in XML-to-JSON workflows. Your code might expect an array and crash when it gets a string, or vice versa. The safe approach is to always check whether the value is an array before iterating, or to configure your converter (if it supports it) to always produce arrays for specific fields.

Text Content and the #text Key

When an element contains only text and no attributes, the value is a simple string. But when an element has both text and attributes, the text needs somewhere to go. The convention is to use a #text key.

XML:

<price currency="USD">29.99</price>

JSON:

{
  "price": {
    "@currency": "USD",
    "#text": "29.99"
  }
}

Without the #text convention, the text content "29.99" would be lost because the object already uses keys for attributes.

CDATA Sections

CDATA (Character Data) sections allow you to include text that would otherwise need escaping — like HTML snippets or code containing < and & characters.

XML:

<description><![CDATA[Use <b>bold</b> for emphasis]]></description>

In JSON, the CDATA wrapper is stripped, and the content becomes a plain string:

{
  "description": "Use <b>bold</b> for emphasis"
}

The angle brackets in the CDATA content are preserved as-is in the JSON string.

Common Pitfalls

Losing Document Order

JSON objects don’t guarantee key order in the specification (though most implementations preserve insertion order). If the order of XML elements carries meaning — for example, steps in a procedure — that ordering may be lost. If order matters, ensure your JSON consumer preserves object key order or convert ordered elements to an array of objects with explicit position fields.

Namespaces Becoming Part of Key Names

XML namespaces produce tag names like <ns:element> or <soap:Body>. During conversion, the prefix becomes part of the JSON key: "ns:element" or "soap:Body". The namespace URI itself (usually declared as an xmlns attribute) isn’t resolved or expanded. If you need to work with namespaced XML, you may need to strip or normalize the prefixes before or after conversion.

Comments and Processing Instructions Disappear

XML comments (<!-- ... -->) and processing instructions (<?xml version="1.0"?>) are discarded during conversion. JSON doesn’t have an equivalent for either construct. If comments carry documentation or metadata you need, extract them separately before converting.

Mixed Content Is Hard to Represent

XML allows text and child elements to be interleaved:

<p>This is <b>bold</b> and this is <i>italic</i> text.</p>

JSON doesn’t have a clean way to represent this interleaving. The converter might produce:

{
  "p": {
    "#text": "This is  and this is  text.",
    "b": "bold",
    "i": "italic"
  }
}

The positional relationship between the text and the inline elements is lost. For mixed content (common in XHTML and document-oriented XML), consider keeping the XML as-is or using a specialized representation like JSON-ML.

All Values Are Strings

XML doesn’t distinguish between <count>42</count> (a number) and <name>Alice</name> (a string). The JSON output treats both as strings. If your application needs typed values, you must apply a schema or post-processing step to parse numbers, booleans, and dates from their string representations.

Comparing XML and JSON Structure

Here is a side-by-side comparison of the same data in both formats to illustrate the structural differences:

XML:

<order id="1001">
  <customer>
    <name>Acme Corp</name>
    <vat>DE123456789</vat>
  </customer>
  <item sku="W-100" qty="3">Widget</item>
  <item sku="G-200" qty="1">Gadget</item>
  <total currency="EUR">89.97</total>
</order>

JSON:

{
  "order": {
    "@id": "1001",
    "customer": {
      "name": "Acme Corp",
      "vat": "DE123456789"
    },
    "item": [
      { "@sku": "W-100", "@qty": "3", "#text": "Widget" },
      { "@sku": "G-200", "@qty": "1", "#text": "Gadget" }
    ],
    "total": {
      "@currency": "EUR",
      "#text": "89.97"
    }
  }
}

The two <item> elements become a JSON array. Attributes get @ prefixes. The <total> element has both an attribute and text content, so #text is used. The root element name becomes the top-level key.

Best Practices

Validate XML before converting. Malformed XML (unclosed tags, unescaped ampersands) will cause parse errors. The XML to JSON Converter reports these errors clearly, but fixing them at the source is better than patching at conversion time.

Handle the single-vs-array ambiguity. If a field can have one or many values, normalize it to always be an array in your application logic. This prevents runtime type errors.

Strip or normalize namespaces. If you don’t need namespace information, remove the prefixes before conversion for cleaner JSON keys.

Post-process for types. After conversion, apply a schema to cast string values to numbers, booleans, or dates where appropriate.

Use the right tool for the job. For one-off conversions and quick inspections, the XML to JSON Converter is fast and private. For automated pipelines, use a dedicated conversion library in your preferred programming language that gives you fine-grained control over the conversion rules.

For other data format conversions, check out the CSV to JSON Converter and YAML to JSON Converter.

Frequently Asked Questions

Is XML-to-JSON conversion reversible?

Not perfectly. The conversion is inherently lossy because JSON can’t represent XML comments, processing instructions, document order guarantees, or the distinction between attributes and child elements without special conventions. If you need round-trip fidelity, use a convention like BadgerFish or JSON-ML that preserves XML semantics at the cost of a more verbose JSON structure.

How are empty XML elements handled?

A self-closing element like <empty/> with no attributes becomes an empty string "". If it has attributes, it becomes an object with only the @-prefixed attribute keys and no #text key.

Can I convert very large XML files?

The converter works well for files up to a few megabytes. For files above 10-20MB, memory limits become a factor. For very large files, use a command-line tool or a streaming XML parser that processes the document without loading it entirely into memory.

Why do some converters produce different JSON for the same XML?

Different converters use different conventions for handling attributes (@, _, -), text content (#text, _text, $), and arrays (always array vs. array only when repeated). There is no single standard for XML-to-JSON mapping. Pick a convention that matches your downstream consumers and stick with it.

Does the converter handle XML schemas (XSD)?

No. The conversion is purely structural — it transforms the XML document as-is without validating against any schema. If you need schema-aware conversion (e.g., knowing that a field should always be an array even when it has one value), apply that logic in a post-processing step.