XML ↔ JSON
How to use this XML/JSON converter
- Choose the direction: "XML → JSON" or "JSON → XML".
- Paste your source data into the left box.
- The converted result appears on the right instantly.
Why convert between XML and JSON?
XML is still common in legacy enterprise systems, SOAP APIs, and configuration files, while JSON is the standard for modern web APIs. This converter helps integrate old and new systems without manually rewriting data structures by hand.
How are XML attributes represented in JSON?
Attributes are placed under an "@attributes" key, and the tag's own text content (if any) under "#text", following a common convention for lossless XML-to-JSON conversion.
Does this handle deeply nested XML?
Yes, the converter recursively processes child elements at any depth, and repeated sibling tags are automatically grouped into arrays.
Why there's no single, universally "correct" way to convert XML to JSON
XML and JSON are structurally fundamentally different formats, which is precisely why no single, universally agreed-upon standard conversion mapping between them actually exists — every XML-to-JSON converter, this one included, has to make its own specific, deliberate design decisions about how to bridge that structural gap. XML elements can simultaneously carry attributes, direct text content, and nested child elements all together at once, while JSON only has objects, arrays, and simple primitive values, with no equivalent, distinct concept of an "attribute" separate from a regular key at all. This is exactly why this tool's own FAQ above specifically documents its particular convention (attributes under "@attributes", text content under "#text") — it's one commonly used, reasonable convention among several genuinely different ones various other tools use, not the single official standard specification, because no single official standard for this specific conversion actually exists in the first place.
Why XML persists in enterprise systems despite JSON's overwhelming modern popularity
As the article above notes, XML remains genuinely common in legacy enterprise systems and SOAP APIs specifically, and understanding why helps explain why a converter tool like this one still has real, ongoing practical value today. XML has considerably more mature, powerful native support for formal schema validation (XSD, XML Schema Definition) than JSON traditionally has had, letting organizations define and strictly enforce precise, rigorous document structure and specific data types — a genuinely valuable property for large enterprise systems, financial data interchange, and regulated industries where strict, verifiable data contracts between systems matter enormously. XML also natively supports namespaces, letting multiple different, unrelated vocabularies coexist safely and unambiguously within a single combined document without their element or attribute names colliding with each other. These specific structural capabilities are exactly why XML, despite JSON's overwhelming popularity for typical modern web APIs, remains genuinely deeply embedded in many long-established enterprise and financial systems that were built around these particular XML-specific capabilities.
The single-versus-array ambiguity — a genuine, real gotcha worth understanding
One of the trickiest, most genuinely error-prone parts of XML-to-JSON conversion is deciding whether a specific repeated tag should become a JSON array or a plain JSON object. If an XML document happens to contain only one single <item> tag, a converter might represent it as a plain object; but if that exact same tag appears twice or more as sibling elements, it needs to become an array instead to hold all of them correctly. This creates a genuinely real practical problem: code written specifically to consume the converted JSON output might work correctly during initial testing (when there was only one single item present) but then break unexpectedly in production the very first time a second sibling item actually appears in real, live data. As the FAQ above notes, this tool specifically handles this by automatically grouping repeated sibling tags into arrays — but being generally aware of this exact ambiguity is genuinely important when writing any code that will actually consume XML-to-JSON converted output downstream.
Why mixed content — text interleaved with child elements — has no clean JSON equivalent
XML explicitly supports what's formally called "mixed content" — an element containing both direct text and child elements interleaved together in a specific, meaningful order, like <p>Hello <b>world</b>, how are you?</p>, where the specific text-versus-element ordering itself genuinely carries real, meaningful information (this is precisely the underlying structure that makes rich-text and document-oriented XML formats work at all). JSON has no clean, natural, equivalent way to represent this same kind of deeply interleaved structure at all, since JSON object keys are fundamentally unordered from a formal specification standpoint, and there's no native JSON concept resembling "text that sits between two specific child elements in a meaningful sequence." This is exactly why XML-to-JSON conversion works cleanly and reliably for data-oriented, primarily structured XML (configuration files, API responses, and similar) but becomes considerably messier, and can genuinely lose real structural information, for document-oriented, richly mixed-content XML like XHTML or DocBook, which were specifically designed around this exact mixed-content capability that JSON simply has no clean way to represent.
Limitations of this tool
This tool converts between XML and JSON entirely within your browser using the specific attribute and text-content convention described in the FAQ above, and as explained there, it correctly handles arbitrarily deep nesting and automatically groups repeated sibling tags into arrays. As explained above, it isn't designed for document-oriented XML with genuine mixed content (text interleaved between child elements in a meaningful order), since JSON has no clean, native way to represent that specific structure — it's best suited for data-oriented XML like configuration files and typical API responses, which is the overwhelming majority of real-world XML-to-JSON conversion use cases in practice.