XML to JSON: the decisions every converter has to make

The ambiguity no converter can avoid

Consider `<items><item>x</item></items>`. Should `item` be a string or a list of one? XML does not say, and the difference matters the moment you write code against it: a consumer expecting always-an-array breaks on a single-element response, and a consumer expecting an object breaks when a second item arrives. Mature converters let you force arrays for known list elements rather than silently guessing, because the guess is right just often enough to reach production.

Attributes need a naming convention

JSON has no attributes, so an attribute has to become either a sibling key or a nested object. The widely used convention prefixes attribute names with `@` — `<image src="a.png"/>` becomes `{"@src": "a.png"}` — while element text goes into a reserved key such as `#text` when an element has both attributes and content. Whatever convention the converter uses, it should be applied consistently, because half-converted XML is worse than unconverted XML.

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

Namespaces

Namespaced documents — SOAP services, sitemaps, Office formats — qualify element names as `ns:element`. JSON has no equivalent, so a converter either drops the prefix, keeps it as part of the key, or rearranges the document around the namespace URI. Dropping it is common and occasionally disastrous when two namespaces use the same local name. If your document uses namespaces, check the output for collisions before trusting it, and prefer keeping the prefix in the key.

Where this conversion is actually used

• RSS and Atom feeds — reading a feed in JavaScript is much easier after conversion.
• SOAP and legacy APIs — turning a response into something a modern client can consume.
• Sitemaps and configuration files — inspecting structure without an editor that understands schemas.
• Data migrations — moving records out of an XML-era system into a JSON-based one.

Round-trip fidelity is a myth. Converting XML to JSON and back rarely returns the original document byte for byte, because declaration order, whitespace, comments and CDATA do not survive. Convert when you need to consume the data elsewhere, not as a backup strategy.

Validate first, then convert

XML parsers are strict about unclosed tags and invalid entities, and the error messages are usually precise. Fix the document before converting — a well-formed input is the only way to get a JSON structure worth keeping. Conversion then runs locally in the browser, which matters when the XML is a customer export or an internal service response, and it keeps working offline.