What is XML ↔ JSON conversion?
XML (Extensible Markup Language) is a tag-based text format for hierarchical data. You'll see it in SOAP web services, RSS and Atom feeds, HL7 FHIR health records, sitemap.xml files, and the configuration files that ship with Maven, Spring, and Android Gradle. JSON (JavaScript Object Notation, defined by RFC 8259) describes the same kind of nested data, but with braces and arrays instead of opening and closing tags. JSON is what almost every REST API speaks today, and it's the native value shape of every browser runtime. Converting between the two formats is one of those jobs that sounds trivial until you hit attributes, mixed content, repeated children, and CDATA. A custom regex is the wrong answer; a real parser is the right one. This tool ships a real parser (fast-xml-parser) and runs it in your browser, so you can paste an XML envelope returned by a legacy SOAP service and watch it become a JSON object you can drop straight into a Redux store, or take a JSON payload you've assembled in a REST client and turn it back into the XML shape an enterprise endpoint still expects.
How does XML ↔ JSON mapping work?
Every conversion runs locally in your browser using the bundled fast-xml-parser library (MIT, version 4.x). The high-level mapping rules are:
- Element to key: each XML element name becomes a JSON object key.
<user><name>Alice</name></user>maps to{"user":{"name":"Alice"}}. - Attribute to prefixed key: an attribute is stored under a key formed by prepending the chosen prefix. With prefix
@,<user id="1">produces{"user":{"@id":"1"}}. - Text content to text-node key: when an element has both attributes and text, the text lands under the chosen text-node key.
<price currency="USD">9.99</price>with key#textproduces{"price":{"@currency":"USD","#text":"9.99"}}. - Repeated children to array: when Force array for repeated child tags is on, multiple sibling elements with the same name collapse into a JSON array.
<items><item>A</item><item>B</item></items>becomes{"items":{"item":["A","B"]}}. - CDATA sections: the raw text inside
<![CDATA[…]]>is preserved under the#cdatakey so angle brackets and ampersands are not re-escaped during the round-trip. - JSON to XML reverses the mapping: object keys become elements, prefixed keys become attributes, and arrays expand into repeated sibling elements.
Why convert XML and JSON with this tool?
- Your data stays on your machine. Every parse and every build runs in this page's JavaScript context. FHIR patient bundles, SOAP authentication envelopes, proprietary config files, billing exports — none of it touches our servers, because there's no upload step in the code path. Open the network panel and watch.
- Legacy SOAP into a REST-first front end is the most common ask we hear. A bank or insurer exposes a SOAP endpoint that won't be retired for years; the React or Vue app calling it doesn't want to learn XML. Paste the envelope, get the JSON back with attributes prefixed and namespaces preserved, drop the
Bodycontents into your state store. - RSS, Atom, and sitemap consumers benefit too. A podcast directory, a news aggregator, or an internal dashboard that ingests
sitemap.xmlcan skip writing an XML parser entirely. Convert the feed once, work with the JSON array, and your client code stays in the language it already speaks. - Configuration export rounds out the list. Maven, Spring, Android Gradle, and old-school Ant builds all emit XML; the cloud-native tooling on the other end (Terraform, Ansible, GitHub Actions, cloud-init) reads JSON or YAML. Convert in the browser instead of running a Python script with a third-party dependency, especially useful in air-gapped environments where pasting into an unknown web service is a non-starter.
What are common applications of XML ↔ JSON conversion?
Bridging XML and JSON comes up across integration engineering, API tooling, and data engineering. A few patterns dominate the workload:
- SOAP to REST bridging: pulling the
Bodypayload out of a SOAP envelope returned by a legacy banking or insurance API and converting it to JSON so a React or Vue front-end can consume it without a server-side proxy layer in front of it. - FHIR health records: converting HL7 FHIR XML bundles (the format required by HHS/ONC and NHS Digital for clinical data exchange) to JSON for loading into a MongoDB Atlas collection or a PostgreSQL JSONB column where analysts can query them.
- Sitemap and feed processing: turning a
sitemap.xmlor an RSS/Atom feed into a JSON array so a custom indexer, a Slack bot, or a dashboard widget can iterate the entries without pulling in an XML parser as a dependency.
What does an XML ↔ JSON round-trip look like?
Take a small example. Paste <user id="1"><name>Alice</name></user> into the input, set attribute prefix to @, leave the mode on XML to JSON, and press Convert. The output is {"user":{"@id":"1","name":"Alice"}}. Flip the mode to JSON to XML, paste that JSON back in, set indent to 2 spaces, and press Convert again. You'll get <user id="1">\n <name>Alice</name>\n</user>, structurally identical to the original. The only thing not guaranteed across the round-trip is attribute order, because JSON object keys are unordered by spec.
This XML ↔ JSON converter ships fast-xml-parser@4 bundled at the same origin, handles attributes, CDATA, repeated child tags, and namespace prefixes, and keeps working offline once the page has loaded. No upload step, no CDN proxy, no analytics beacon, no telemetry of any kind. Every byte of input and output stays in your browser, which is exactly what you want when the payload happens to be a FHIR patient bundle, a SOAP authentication envelope, or any other shape of data that nobody outside your team should ever see.