XML to JSON Converter
Convert XML to JSON — attributes preserved with an @_ prefix, invalid markup reported with exact line and column.
Angle brackets in, JSON out
SOAP responses, RSS feeds, legacy exports, configuration dumps — XML sources are everywhere, and modern code wants JSON. This converter validates the markup first (malformed XML gets an exact line:column error, not a shrug), then maps the document: elements become keys, text becomes values, repeated sibling tags become arrays.
How attributes and text are kept
<book id="42" lang="en">
<title>Dune</title>
</book>
{
"book": {
"@_id": 42,
"@_lang": "en",
"title": "Dune"
}
} XML carries information JSON has no native slot for — attributes. Dropping them would lose data, so they are kept with an @_ prefix, cleanly distinguishable from child elements. Numeric-looking text is typed as numbers; pure whitespace is trimmed.
The one structural ambiguity to know about
XML cannot express "this is a list with one entry" — a single <item> child converts to an object, two or more convert to an array. Every XML-to-JSON mapper on earth shares this ambiguity, because the information simply isn't in the source. If your code expects an array, normalize after conversion (Array.isArray(x) ? x : [x]) — and inspect the structure comfortably in the tree viewer first.
Frequently asked questions
What does the @_ prefix in the output mean?
Those are the XML attributes. <book id="42"> becomes "@_id": 42 inside the book object. The prefix keeps attributes distinguishable from child elements of the same name — remove or rename them in your code if the distinction does not matter to you.
Why is my single list entry an object instead of an array?
XML has no array marker: one <item> child is indistinguishable from "a single object". With two or more siblings the converter emits an array. Normalize in code if you always need arrays — this ambiguity is inherent to XML, not to this tool.
Are namespaces (ns:tag) supported?
Yes — namespaced element names are kept verbatim as keys ("soap:Envelope"). Nothing is stripped, so round-tripping into namespace-aware tooling stays possible.
How are CDATA sections and comments handled?
CDATA content becomes the string value of its element (that is what CDATA means). XML comments have no JSON equivalent and are dropped.
My XML is rejected — where do I look?
The error message includes the exact line and column from the validator. The usual suspects: an unclosed tag, a bare & (must be &), or multiple root elements. Fix the markup and convert again.