Free XML to JSON Converter
Convert XML to JSON instantly. Handles attributes, nested elements, and text nodes. Runs entirely in your browser.
What is XML?
XML (Extensible Markup Language) is a format for storing and transporting data. It uses custom tags to describe data structure, making it human-readable and widely supported. Unlike JSON, XML can include attributes on elements.
Why Convert XML to JSON?
- Smaller file size · JSON is more compact than XML.
- Web APIs · Most modern web services use JSON instead of XML.
- Easier parsing · JSON maps directly to JavaScript objects.
- Legacy system integration · Convert old XML data to modern JSON format.
Frequently Asked Questions
How are XML attributes handled?
XML attributes are converted to JSON properties with an @ prefix (e.g., @id, @href). This preserves attribute information in the JSON structure.
What about namespaces?
Namespaces are preserved in the output. Prefixes are included in the element names (e.g., "ns:element").
Can I convert JSON back to XML?
This tool converts XML to JSON. For the reverse, you can use our JSON to XML converter.
Two formats, three decades apart
XML 1.0 became a W3C Recommendation on 10 February 1998. The original editors were Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) and C. M. Sperberg-McQueen (University of Illinois at Chicago); the Working Group was chaired by Jon Bosak of Sun Microsystems. XML's lineage runs back to SGML (ISO 8879:1986), the document-markup standard that itself grew from IBM's GML in the 1970s. SGML was powerful but daunting; XML's design brief was "design a 'lite' version of SGML", trimming optional features to a profile that could be implemented in a few thousand lines of code while preserving Unicode, namespaces and attribute-rich documents.
JSON (JavaScript Object Notation) was discovered, not designed. Douglas Crockford and Chip Morningstar sent the first JSON message in April 2001 at State Software, deriving the format from JavaScript's object-literal syntax. Crockford registered json.org in 2002 and put up a one-page spec. The format was first formalised as RFC 4627 in July 2006, re-issued as RFC 7159 in 2014, and stabilised as RFC 8259 / STD 90 in December 2017, the same year ECMA-International published ECMA-404. JSON's design intent (per Crockford's retrospective): minimal, language-independent, easy to generate and parse, no version number ("there is no version number"), and deliberately no comments ("I removed comments because I saw people were using them to hold parsing directives").
JSON took over web APIs in the late 2000s as REST replaced SOAP and as XMLHttpRequest gave way to JSON-over-fetch. By 2015 JSON was the default response format of nearly every public API; XML survived in long-tail enterprise SOA, document formats (Office Open XML, OpenDocument), and standards-bound niches.
Where XML and JSON differ
| XML | JSON | |
|---|---|---|
| Attributes | First-class (<item id="5"/>) | No attributes, everything is a key/value pair |
| Namespaces | Native (xmlns:prefix="uri") | Flat names; prefix collisions are the app's problem |
| Comments | <!-- … --> | None per spec |
| Mixed content | Native (<p>text <b>and</b> markup</p>) | Awkward, needs arrays or stringification |
| Schema | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema (community spec, draft 2020-12) |
| Order | Element order is significant per spec | Object key order not guaranteed (most parsers preserve insertion order in practice); arrays are ordered |
| Numbers | Strings until typed by schema | IEEE 754 double; no integer/float distinction at spec level |
| Verbosity | High (every value wrapped in tags | Low) punctuation only |
Why XML→JSON is fundamentally lossy
There is no W3C-blessed canonical mapping from XML to JSON. Every converter has to invent answers to questions XML allows you to express but JSON has no native vocabulary for. The recurring decisions:
- Attributes vs child elements: XML lets you express the same data both ways. JSON has only one notion (keys on an object), so the converter must invent a marker. The common conventions: BadgerFish uses
@for attributes and$for text; Parker drops attributes entirely (lossy but simple); JsonML represents elements as arrays with type tags (preserves order and structure); GData / Newtonsoft / xml2js use an@attributessub-object plus a#textkey when needed. This converter follows the GData-style convention: attributes under@attributes, mixed-content text under#text, repeated children become arrays. - Repeated child elements: if the converter blindly creates one key per child, the second child overwrites the first. Standard fix: detect repetition and emit an array. But this means the JSON shape depends on data, one
<book>produces a string, two produce an array of strings. Some consumers want the array form even for one item; some converters expose an "always-array" toggle for specific element names. - Mixed content:
<p>Hello <b>world</b>!</p>intermixes text and elements with significant order. JSON cannot natively express that interleaving without an array of mixed types or a sentinel#textkey. Many converters drop the prose between elements; the more conservative ones split it into multiple text-node entries. - Namespaces:
<soap:Envelope xmlns:soap="…">has both a prefix and a binding URI. Most converters preserve the prefix as part of the JSON key (soap:Envelope) and drop the binding, which is fine as long as the consumer doesn't need to resolve the namespace. - Comments and processing instructions: usually dropped silently, since JSON has no comment syntax.
- CDATA sections: flattened to plain strings; the
<![CDATA[…]]>wrapper is lost. - Whitespace: XML has
xml:space="preserve"for significant whitespace; JSON has no equivalent. Most converters trim whitespace-only text nodes between elements.
When you'd reach for this
- Consuming legacy SOAP services from a modern JS frontend. SOAP responses are XML; converting once at the boundary lets the rest of the app work in JSON.
- RSS / Atom feed processing: both are XML formats; modern news readers and aggregators usually want JSON.
- XML sitemaps (
sitemap.xml), converting to JSON makes them easier to inspect and process programmatically. - OpenStreetMap OSM data: published as XML, frequently needed as JSON for client-side mapping.
- Google Earth KML / GPX files: geographic data formats that come in XML.
- Office Open XML internals:
.docx,.xlsxand.pptxare zipped XML files; if you've extracted one and want to inspect its structure as JSON, this is the conversion step. - SVG manipulation: SVG is XML. Converting to JSON makes it easier to walk and mutate the tree in JavaScript before re-serialising.
- Maven POM, Ant build files, Spring config, Android resources, Apple plists, XBRL financial data, HL7 medical records, MusicXML, NMX legal documents: long-tail XML formats that often need JSON for downstream tooling.
Modern alternatives
- Native JSON APIs. If the upstream service offers a JSON variant, take it. SOAP services typically don't but most modern equivalents do.
- GraphQL. A query language that lets the client request exactly the JSON shape it needs from a typed schema.
- Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Binary serialisation formats with schemas and much smaller wire sizes than either XML or JSON. Common inside microservice meshes; rarely used at the browser boundary because they need explicit decoding libraries.
- Stay in XML. If the data is genuinely document-oriented (mixed content, deep typed structure, schema validation that matters), XML is the better fit. JSON's strength is API-shaped data; document fidelity isn't its specialty.
More questions
Why does the same XML produce a different JSON shape on different tools?
Because there is no canonical XML→JSON mapping. Each converter picks a convention (BadgerFish, Parker, JsonML, GData-style) and the resulting JSON shapes differ in how attributes are marked, how mixed content is preserved, and how repeated children are arrayed. Round-tripping XML through different converters produces different JSON; round-tripping JSON back to XML through different converters can change attribute placement and even element ordering. For interoperability, document the convention you're using and stick to it.
What about CDATA, comments and processing instructions?
CDATA sections (<![CDATA[…]]>) are flattened to plain string content, the wrapper is gone, but the text inside is preserved verbatim. XML comments (<!-- … -->) and processing instructions (<?xml-stylesheet …?>) are dropped, since JSON has no syntax for either. If you need round-trip fidelity that preserves comments, an XML-only round trip is the right approach.
Will my XML schema (XSD) survive the conversion?
No. XSD describes XML structure and types; JSON Schema is the analogous (separate) standard for JSON. Some advanced tooling can translate XSD to JSON Schema, but it's a lossy operation, XSD has features (mixed content, substitution groups, derived types) that have no clean JSON Schema equivalent. For document validation that matters, run XSD against the original XML, not against the JSON conversion.
Why did JSON win for web APIs?
A few reasons. JSON maps directly to JavaScript objects, so browser-side parsing is one JSON.parse() call away. The format is much smaller, no closing tags, no namespace declarations, no schema baggage. REST replaced SOAP for most public APIs in the late 2000s, and JSON was the natural payload for REST. XML's strengths (strict schemas, namespaces, mixed content) matter for documents and legacy enterprise systems but rarely for "give me the user object." The web optimised for the simpler case.
Does anything get sent to a server?
No. The XML is parsed by the browser's native DOMParser, then walked recursively in JavaScript to build the JSON output. Pasted XML never leaves the page. The tool works offline once it's loaded, which matters when the source XML contains internal API endpoints, customer data, or proprietary schemas you'd prefer not to upload anywhere.