XML to JSON Converter

The attribute forces the element to become a JSON object rather than a plain string, since a plain string value has nowhere to hang the attribute. The text content moves to a #text key alongside the attribute key: {"price": {"@currency": "USD", "#text": "19.99"}}. If the element had no attributes, the same tag would have simplified to a plain string value instead.

Per the XML 1.0 spec, a self-closing tag and an explicitly-closed empty tag are equivalent — there's no way to distinguish them once parsed, so both convert identically. With no attributes and no text or child content, there's nothing to populate the JSON value with, so this typically comes through as an empty string or null rather than an empty object, since there are no attribute or child keys to place inside one.

No. JSON's grammar (RFC 8259 / ECMA-404) has no comment syntax and no node type analogous to a processing instruction (<?xml-stylesheet type="text/xsl" href="style.xsl"?>), so both are stripped during conversion. Only element structure, attributes, and character data survive the conversion; anything that isn't data in the XML infoset sense is discarded.

Two separate spec gaps compound here. First, XML often contains whitespace-only text nodes between elements purely for pretty-printing indentation, which can surface as stray #text entries unless explicitly stripped. Second, the JSON grammar (ECMA-404) never mandates that object members preserve insertion order — most parsers do in practice, but it isn't a spec guarantee — so attribute order captured as @keys isn't reliably round-trippable either.

This is an inherent ambiguity, not a bug in any particular tool. XML has no native numeric or boolean type — per the XML 1.0 spec, every element's content is character data — so an XML-to-JSON conversion always has to make a judgment call about when text should become a JSON number/boolean versus staying a string. That judgment call is genuinely dangerous for values like "007" (a zip or product code, not the number 7) or "1.50" (a price, where casting to a number silently drops the trailing zero as 1.5). The safe default, and the one most conversions favor, is to leave all element and attribute values as JSON strings and let the consuming code decide when and how to cast — that way no information is silently destroyed.

Browsers and Node.js have no built-in equivalent of JSON.parse for XML — you'd need DOMParser (browser-only) or an XML library (Node), then hand-write traversal code to pull values out of the DOM tree via getElementsByTagName or XPath. JSON.parse, by contrast, is a single built-in call that hands you plain objects and arrays you can destructure immediately. That gap is exactly why legacy SOAP APIs, RSS/Atom feeds, and sitemap.xml files so often get converted to JSON at the edge of a JavaScript codebase: it's not that JSON is more powerful, it's that the JS tooling for consuming it is already there.

XML predates JSON by roughly a decade: XML 1.0 became a W3C Recommendation in February 1998, derived from SGML and designed as a document markup language (hence attributes, mixed content, and namespaces). JSON was extracted from JavaScript's object-literal syntax by Douglas Crockford in the early 2000s, first formally specified as RFC 4627 in 2006, then re-specified as ECMA-404 (2013) and its current form, RFC 8259 (2017). JSON's minimalism — four data types, no attributes, no mixed content — reflects its origin as a wire format for passing data structures to and from a running program, not for marking up documents.

No — and the @-prefix convention this tool uses for attributes is itself evidence of the gap. That convention (@key for attributes, #text for mixed content) is not part of the JSON specification; it's a widely-used but informal convention, and different XML-to-JSON tools handle the same input differently — some flatten attributes into plain keys, some wrap element content in a $ or _text key, some use the BadgerFish or Parker conventions. JSON has no built-in concept of an attribute at all, so any XML-to-JSON tool is layering its own convention on top of plain JSON objects, and JSON output from one converter won't necessarily match another's for the same XML input.

Because this converter preserves namespace prefixes literally as part of the key name rather than resolving them to their full namespace URI, "a:id" and "b:id" convert to two distinct JSON keys and won't collide — but only as long as the prefixes themselves differ. If two different parts of a document happen to use the same prefix for different namespace URIs (legal in XML, since prefix bindings are scoped to the element they're declared on), or if a tool downstream re-parses the JSON without namespace context, that prefix-based key no longer reliably identifies which namespace the element actually belonged to. For documents where namespace URIs matter more than prefixes, it's safer to normalize prefixes before conversion.