XML to JSON Converter
Convert well-formed XML to either practical compact JSON or an order-preserving node representation, with explicit handling notes for attributes, namespaces, mixed content, whitespace, CDATA, comments, and processing instructions.
0 characters
JSON output
Converted JSON will appear here...
The XML is parsed locally, not validated as an application contract
Parsing and mapping happen in the browser with DOMParser; parsed values are serialized as JSON text rather than inserted into the active page. DOCTYPE input is rejected before parsing. A successful conversion still does not mean the document satisfies an XSD, DTD, SOAP profile, feed format, or business rule.
XML and JSON do not share one universal data model
JSON has objects, arrays, strings, numbers, booleans, and null. XML has elements, attributes, ordered child nodes, namespace bindings, character data, comments, processing instructions, CDATA sections, and document-level syntax. A JSON representation therefore has to choose what to preserve and what to simplify; there is no single standard mapping hidden inside every XML document.
Compact mapping works well for element-centric API data. Ordered mapping stays closer to the parsed XML node sequence when mixed content, namespaces, comments, processing instructions, or exact child order matter. The underlying XML concepts are defined by XML 1.0.
How compact mapping turns XML features into JSON
| XML feature | Compact representation |
|---|---|
| Leaf element | Direct character data becomes a JSON string when there are no attributes or child elements. |
| Attributes | Collected under @attributes using qualified attribute names. |
| Text beside attributes/children | Collected under #text. |
| Repeated child names | Become an array under that qualified child name. |
| CDATA | Merged into text, so the CDATA boundary is no longer distinguishable. |
| Comments / processing instructions | Omitted in compact mode and reported in the mapping notes. |
Element-centric data stays compact
<book id="7"> <title>XML in Practice</title> <tag>api</tag> <tag>data</tag> </book>
{
"book": {
"@attributes": { "id": "7" },
"title": "XML in Practice",
"tag": ["api", "data"]
}
}Mixed content needs sequence
<p>Hello <strong>world</strong>!</p>
The words before and after strong are separate text nodes. Grouping child elements by name cannot say that Hello came first and ! came last. Ordered mapping keeps those nodes in sequence.
A namespace prefix is only a label
Namespace identity comes from the namespace URI, not from the particular prefix written in the file. Two documents can use different prefixes for the same vocabulary, and the same prefix can be rebound in different scopes. Namespaces in XML defines that relationship.
Compact mapping keeps qualified names such as soap:Body and the namespace declaration attributes but does not attach a namespace URI to every element. Ordered mapping records name, localName, prefix, and namespaceURI separately. Unprefixed attributes remain in no namespace even when a default element namespace is active.
Whitespace can be data
Pretty-printed API XML often contains indentation that is not useful in the resulting data model, while prose, source code, signatures, and other document-oriented XML can depend on whitespace. Compact mapping trims direct text by default; the checkbox keeps it, and an inherited xml:space="preserve" request also keeps it.
XML 1.0 describes xml:space and application whitespace handling. Values other than default and preserve are reported because assigning them a private meaning would make the mapping harder to reason about.
DOCTYPE and entity-dependent XML need an XML-native path
A DTD can declare entities, default attributes, and validity constraints. External entity handling has also been a security-sensitive area in server-side XML stacks. DOCTYPE input is rejected before browser parsing so the page does not pretend to support DTD-dependent documents or external entity resolution.
The five predefined XML entities and numeric character references do not require a DTD. After parsing, references have already become characters, so the JSON cannot tell whether a character was written literally, with &#x..., or with a predefined entity such as &.
Well-formed is not the same as valid for your system
Browser DOMParser can identify malformed XML such as mismatched tags or unbound namespace prefixes. MDN documents that XML parsing returns a document containing a parsererror node when parsing fails; browser engines do not expose one universal exception object for every XML parse error. See DOMParser.parseFromString() for that browser behavior.
Passing the parser only establishes a browser-parsed XML document. It does not check XSD, Relax NG, DTD validity, SOAP rules, RSS/Atom profiles, or application-specific constraints. A perfectly well-formed document can still be unusable by the receiving system.
What cannot be reconstructed after parsing
- The XML declaration is not represented as an ordinary child node; a pasted string also cannot prove the original byte encoding named by that declaration.
- Character and predefined entity references are resolved to characters.
- Compact mapping loses exact sibling sequence across differently named children, CDATA boundaries, comments, processing instructions, and some namespace identity detail.
- Ordered mapping keeps far more of the parsed node model but still loses lexical choices such as quote style, exact entity spelling, original byte encoding, and source formatting.
- Attribute and text values remain strings.
"001","true", and an empty string are not guessed into numbers, booleans, or null.
Choose the next step from what you are trying to preserve
If readability is the only goal, keep the data as XML and format it. If a JSON contract is the goal, decide explicitly how attributes, namespaces, arrays, mixed content, and types should map before making that representation part of an API.