XML to JSON

An XML-to-JSON converter walks an XML document tree and emits a JSON value that represents the same hierarchy. Every element becomes an object, every attribute is folded into that object under a convention-driven key (often prefixed with @), text content lives under another conventional key (often #text), and repeated sibling elements collapse into a JSON array. The result is not XML written differently; it is XML reshaped into the only two container types JSON has — objects and arrays.

Why convert in this direction at all

XML still dominates feeds, configuration files, legacy SOAP services, and many enterprise document exchanges. JSON dominates modern HTTP APIs, JavaScript runtimes, and most debugging tools. Converting XML to JSON is the bridging step whenever data that arrived as XML has to be consumed, displayed, or queried by something that only speaks JSON — without rewriting either side of the connection.

How XML constructs map onto JSON, and where they cannot

JSON has objects, arrays, strings, numbers, booleans, and null. XML has elements, attributes, mixed text, namespaces, processing instructions, CDATA, and ordering rules. Most XML constructs do map onto JSON, but the mapping is by convention rather than by specification — every converter picks one. Knowing the convention this tool uses makes it much easier to audit the output and to predict what downstream code will see.

• Each element becomes a JSON object keyed by its tag name; nested elements live as nested objects under that key.
• Attributes fold into the same object under a conventional prefix (commonly @attr) so they do not collide with child element names.
• Text content sits under a conventional key (often #text or _), used only when an element also has attributes or children alongside its text.
• Two or more sibling elements with the same tag name collapse into an array under that key — but a single child element with that name stays as an object. Downstream code has to handle both shapes.
• Namespaces are kept as part of the tag name (prefix:tag) unless the converter is told to strip them — silently dropping a namespace is the fastest way to make two superficially identical documents mean different things.

Rule of thumb: write down which convention you expect (attribute prefix, text key, array policy, namespace handling) before you start auditing. The output is only wrong relative to a convention you have decided on.

How to use this tool

1. Prepare representative XML documents that need API-friendly or parser-friendly structured output in XML to JSON instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate JSON text that reflects the XML hierarchy for review, and review attributes, repeated elements, text-node content, namespaces, and whether the source XML mixes data with presentation structure before deciding the result is ready.
3. Only copy or download the result after it fits API migration, support debugging, import prep, and XML cleanup and no longer conflicts with this constraint: XML attributes, namespaces, and repeated nodes can flatten in ways that need manual review after conversion.

XML to JSON example

This XML to JSON example uses representative XML documents that need API-friendly or parser-friendly structured output and shows the resulting JSON text that reflects the XML hierarchy for review, so you can confirm attributes, repeated elements, text-node content, namespaces, and whether the source XML mixes data with presentation structure before applying the same settings to real input.

Sample input

<item><name>ToolKit</name><active>true</active></item>

Expected output

{
  "item": {
    "name": "ToolKit",
    "active": "true"
  }
}

A small XML document and the JSON it produces

<!-- XML -->
<library>
  <book id="1" lang="en">
    <title>XML in a Nutshell</title>
    <author>Eckstein</author>
  </book>
  <book id="2" lang="en">
    <title>Effective Java</title>
    <author>Bloch</author>
  </book>
</library>

// JSON
{
  "library": {
    "book": [
      { "@id": "1", "@lang": "en", "title": "XML in a Nutshell", "author": "Eckstein" },
      { "@id": "2", "@lang": "en", "title": "Effective Java",   "author": "Bloch" }
    ]
  }
}

Notice that the two sibling book elements collapse into an array, while attributes (@id, @lang) live alongside child element keys inside the same object. If there had been only one book element, book would be an object instead of an array.

When converting XML to JSON is the right step

The conversion is most useful at the boundary where XML-producing systems meet JSON-consuming ones. Once the data crosses that boundary, every downstream tool gets cheaper to integrate with.

• Importing an RSS or Atom feed into a JavaScript-based reader or research script that has no XML parser in its stack.
• Quickly inspecting a complex XML response by browsing the converted JSON in DevTools.
• Bridging a legacy SOAP service to a modern HTTP API at the gateway layer.
• Feeding XML configuration into a JSON-only validator, linter, or schema-inference tool.
• Sharing a partner's XML export with non-engineering teammates without making them install a viewer.

Edge cases worth double-checking after the conversion

XML can express things JSON cannot. Most surprising results from this conversion are not bugs — they are the spots where the source XML relied on something the JSON convention had to flatten, rename, or drop.

• Element order: XML preserves it; JSON object keys do not. If order matters, keep children as a JSON array rather than promoting them to object keys.
• Mixed content: an element with both text and child elements has no clean JSON shape; converters usually split it into chunks, which is lossy for document-style XML.
• Namespaces: stripping the prefix may make the JSON look cleaner but silently merges elements XML treated as different. Keep prefixes when in doubt.
• Numeric-looking strings: an XML value like 007 is text. If the converter coerces it to a number, leading zeros disappear and downstream comparisons fail.
• CDATA blocks: contents must stay verbatim. A converter that strips wrapping CDATA markers is fine; one that re-escapes or trims the body is not.

Practical Notes

• Review attributes, repeated elements, text-node content, namespaces, and whether the source XML mixes data with presentation structure before you reuse the JSON text that reflects the XML hierarchy for review.
• XML attributes, namespaces, and repeated nodes can flatten in ways that need manual review after conversion.
• Keep the original XML documents that need API-friendly or parser-friendly structured output available when the result affects production work or customer-visible content.

XML to JSON reference

XML to JSON reference content should stay anchored to XML documents that need API-friendly or parser-friendly structured output, the generated JSON text that reflects the XML hierarchy for review, and the checks needed before API migration, support debugging, import prep, and XML cleanup.

• Input focus: XML documents that need API-friendly or parser-friendly structured output.
• Output focus: JSON text that reflects the XML hierarchy for review.
• Review focus: attributes, repeated elements, text-node content, namespaces, and whether the source XML mixes data with presentation structure.

References

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• W3C: Extensible Markup Language (XML) 1.0