Migrating legacy XML APIs to JSON
One of the most common tasks in enterprise software modernisation is wrapping a legacy XML API in a JSON-friendly adapter. The internal system keeps running — changing it is too risky or too expensive — but modern clients (mobile apps, React frontends, third-party integrations) need JSON. The adapter layer converts incoming JSON requests to XML for the legacy system and converts XML responses back to JSON for the client.
The tricky part is that XML and JSON have fundamentally different data models. XML is a tree of elements with text content and attributes. JSON is a tree of objects, arrays, strings, numbers, booleans, and nulls. The conversion is lossy in both directions — XML attributes have no JSON equivalent, and JSON arrays of mixed types have no clean XML equivalent.
For a migration project, the recommended approach is: convert a representative set of XML responses to JSON, show them to the team that owns the consuming applications, agree on a JSON schema, and then write the conversion code to produce that exact schema rather than using a generic converter. Generic converters are excellent for exploration and one-off transformations — but for a production API, you want a deterministic, validated mapping.
XPath vs JSONPath
XPath is the query language for XML documents. It's built into every XML parser and supported natively in browsers (document.evaluate()), XSLT, and server-side XML libraries. An XPath expression like //user/address/city selects all city elements that are children of address elements anywhere in the document.
JSONPath is the JSON equivalent, popularised by Stefan Goessner's 2007 article. The same query in JSONPath is $..address.city. JSONPath is supported by libraries like jsonpath-plus (JavaScript) and jsonpath (Python), and is used in tools like Kubernetes JSON patches, AWS EventBridge event patterns, and Postman test scripts.
When migrating from XML to JSON, you'll often need to rewrite XPath queries as JSONPath queries. The main conceptual difference: XPath distinguishes between elements and attributes (@id selects the id attribute), while JSONPath treats everything as key-value pairs. XPath also has more powerful axes (parent, sibling, ancestor), which JSONPath doesn't fully replicate.
XML-to-JSON libraries: fast-xml-parser, xml2js
For production use in Node.js, two libraries dominate XML-to-JSON conversion:
fast-xml-parser — the current community favourite. Zero dependencies, well-maintained, supports XML attributes, CDATA, namespaces, and has detailed options for controlling how arrays and attributes are mapped. It's also one of the fastest pure-JavaScript XML parsers available. Install: npm install fast-xml-parser.
xml2js — the long-standing default. Older API, slightly slower, but battle-tested with many years of production usage. Has a large number of configuration options including explicitArray (whether single-child elements become arrays) and mergeAttrs (whether attributes are merged into the element object rather than nested under $).
In Python, xmltodict is the idiomatic choice — it converts an XML string to a Python OrderedDict that mirrors the structure, and json.dumps(xmltodict.parse(xml_string)) is a common one-liner for quick conversions. For more control, Python's standard library xml.etree.ElementTree gives you full programmatic access to the parsed tree.
Handling XML attributes vs elements
The most contentious XML-to-JSON design decision is how to handle attributes. In XML, both <user id="42">Alice</user> and <user><id>42</id><name>Alice</name></user> are valid ways to model the same data. In JSON, there's only one way: key-value pairs in an object.
This tool uses the @attributeName convention to represent attributes. It's not the only convention, but it's one of the most common and makes it easy to distinguish attributes from child elements at a glance. Other libraries use a nested $ object (xml2js default) or flat merge (when attributes are rare and name collisions are unlikely).
CDATA sections (<![CDATA[...]]>) are a related gotcha. CDATA exists in XML to allow literal text containing special characters (like < and &) without entity encoding. In JSON, strings can contain any character directly (with standard JSON string escaping), so CDATA has no equivalent — it just becomes a string value.
Parsing XML in production
Parsing XML in production? Sentry catches the malformed-payload errors you'd never see otherwise
A third-party XML API returns a stray & in a product description and your parser throws. The request fails silently. You find out when your customer reports missing data. Sentry captures the raw XML payload alongside the full stack trace — so you can reproduce the exact failure, patch the parser or sanitiser, and add a regression test. No more "it works in staging."
Free plan: 5K errors/mo. No CC.
Frequently Asked Questions
How does the converter handle XML attributes?
XML attributes are included in the JSON output with an @ prefix on the key name (e.g., an attribute id="42" becomes "@id": "42" in the JSON object for that element). This is a widely-used convention from libraries like fast-xml-parser and xml2js that makes it easy to distinguish attributes from child elements in the output.
When do same-named elements become an array vs a single value?
When multiple sibling elements share the same tag name, they are grouped into a JSON array. For example, two <tag> elements become "tag": ["value1", "value2"]. A single <tag> element stays as "tag": "value". This is the most natural mapping, but it means the JSON shape for a field can vary depending on how many elements appear in the XML — a common source of bugs when you assume a field is always an array or always a string.
Does this converter handle CDATA sections?
Yes. CDATA sections (content wrapped in <![CDATA[ ... ]]>) are treated as text content by the browser's DOMParser, which this tool uses internally. The CDATA wrapper is stripped and the raw text content is included in the JSON output as a string value. Special characters inside CDATA are preserved as-is since they don't need entity escaping.
What happens to XML comments and processing instructions?
XML comments (<!-- ... -->) and processing instructions (<?target data?>) are ignored by the converter. Only element content, text nodes, and attributes are included in the JSON output. If you need to preserve comments, post-process the XML with a full DOM parser that exposes comment nodes before converting.
Is this XML to JSON converter safe for sensitive data?
Yes. The conversion uses the browser's built-in DOMParser API — no data is transmitted to any server. You can verify this by opening your browser's DevTools Network tab and watching for zero outbound requests when you paste and convert. Your XML data never leaves your machine.