XML to JSON Converter
Paste XML and get JSON instantly, with attributes, nested hierarchies, and text nodes mapped predictably, all processed locally in your browser.
What it does
- Attributes mapped to @-prefixed keys, element text under #text
- Handles nested hierarchies and repeated elements
- Safe for internal SOAP, WSDL, and config XML
- Runs locally, no data leaves the browser
Convert XML to JSON in your browser so you can feed legacy SOAP/WSDL responses, RSS feeds, vendor exports, or config files into a modern REST, JavaScript, or microservice workflow, and nothing you paste is ever uploaded. Everything runs locally on your device, which means you can point this at internal or proprietary XML without writing xml2js or xmltodict glue code and without trusting an unknown server.
What this conversion actually does (and does NOT do)
This is a lossy, structure-reshaping conversion, not a reversible byte transform like Base64. XML's document model is richer than JSON's data model, so round-tripping XML to JSON and back to XML is not guaranteed to reproduce your original file byte for byte. The converter reshapes the tree into JSON objects and arrays following documented, deterministic rules.
Attributes have no native JSON equivalent, so they are conventionally mapped to keys with an @ prefix: <book id="1"> becomes {"book":{"@id":"1"}}. When an element holds text alongside attributes or child elements, that text is stored under a #text key so it does not collide with the structured fields.
The single most common real-world surprise is the single-versus-repeated element ambiguity. One <item> becomes a JSON object, but two or more <item> elements become a JSON array. Consuming code that always expects an array will break on the single-item case, so plan your downstream parsing around that behavior. Namespaces are another rough edge: JSON has no concept of XML namespaces, so a prefix like ns:tag is either kept in the key or stripped, and there is no universally correct choice. Mixed content, an element holding both free text and child elements, maps awkwardly because JSON objects cannot natively interleave text and structured fields.
Several things are dropped entirely. XML comments, processing instructions, CDATA wrappers, and DOCTYPE/DTD declarations generally have no JSON representation, so they are flattened or discarded. Note also that JSON output is usually smaller than the source XML, since there are no closing tags and far less verbose markup, which is one reason teams convert XML for API payloads and reduced bandwidth.
When to choose XML to JSON
Choose this conversion when you are modernizing SOAP or WSDL responses for a REST or JavaScript client, ingesting XML feeds into JSON-native pipelines, or simply inspecting an unfamiliar XML structure. Keep working in XML when you genuinely need attributes preserved with fidelity, namespaces, comments, schema validation, or XSLT transforms, because those concepts do not survive the trip. If your goal is the opposite direction or a different tabular shape, the CSV / JSON converter handles row-oriented data, and the JSON formatter can pretty-print or validate the result you get here.
How to convert
- Paste your XML into the input box, or load a SOAP/WSDL response, feed, or config file's contents.
- The tool converts it to JSON in a single direction, applying the attribute, array, and text-node rules described above.
- Review the JSON output, then copy it to your clipboard or download it as a file.
No upload. It runs on your device.
The conversion engine is written in Rust and compiled to WebAssembly that runs entirely inside your browser tab. There are zero network requests for processing, the tool keeps working after the page has loaded even if you go offline, and there is nothing to delete afterward because nothing was ever uploaded. You can confirm this yourself by opening your browser's DevTools Network tab and watching it stay silent while you convert. That matters here because XML payloads often carry sensitive material: internal SOAP and WSDL responses, vendor data exports, or config files that may embed credentials, customer records, or proprietary schema. This is the converter you can safely point at production XML.
No limits
No file-size caps, no rate limits, no watermarks, no sign-up, and no ads. Convert as much XML as you need, as often as you need.
Frequently asked questions
- How are XML attributes represented in the JSON output?
- Attributes have no native JSON equivalent, so they are conventionally mapped to keys with an
@prefix, meaning<book id="1">becomes{"book":{"@id":"1"}}. When an element has both attributes and text content, the text is stored separately under a#textkey so the two never collide. - Why does a single repeated element become an object instead of an array, and can I force an array?
- One occurrence of an element becomes a JSON object, while two or more occurrences become a JSON array, because the converter infers the shape from how many times the element appears. This is the most common source of downstream bugs, so if your consuming code always expects an array you should normalize the single-item case in your own parsing rather than assuming it is already a list.
- Is the XML to JSON conversion reversible?
- No, this is a lossy, structure-reshaping conversion rather than a reversible byte transform. XML's document model is richer than JSON's, so converting JSON back to XML is not guaranteed to reproduce your original file, especially once comments, namespaces, and mixed content are involved.
- How are XML namespaces handled in the converted JSON?
- JSON has no concept of XML namespaces, so a converter must either keep the prefix inside the key (such as
ns:tag) or strip it away. There is no universally correct choice, so check the output keys and adjust your downstream mapping accordingly. - What happens to mixed content with both text and child elements?
- Mixed content, where an element holds free text alongside child elements, maps awkwardly because JSON objects cannot natively interleave text and structured fields. The text is typically captured under a
#textkey while the child elements become sibling properties, which preserves the data but flattens the original ordering. - Are XML comments, CDATA, and DOCTYPE declarations preserved?
- No, XML comments, processing instructions, CDATA sections, and DOCTYPE/DTD declarations generally have no JSON representation. They are dropped or flattened during conversion, so do not rely on JSON output to retain any of those constructs.
- Can I convert a SOAP or WSDL response to JSON?
- Yes, SOAP and WSDL payloads are just XML, so they convert the same way as any other XML document. Because everything runs locally in your browser with no upload, this is a safe way to reshape internal or proprietary SOAP responses without sending them to a third-party server.
- Is my XML uploaded to a server?
- No, the conversion runs entirely in your browser via Rust compiled to WebAssembly, with zero network requests for processing. You can verify this in your browser's DevTools Network tab, and the tool continues to work even if you disconnect from the internet after loading the page.
- Why is the JSON output smaller than my XML input?
- JSON output is typically smaller than the source XML because it has no closing tags and uses far less verbose markup. That size reduction is part of why teams convert XML to JSON for API payloads and to cut bandwidth.
Explore more text and data tools, pretty-print your result with the JSON formatter, or reshape tabular data with the CSV / JSON converter.