Upload an XML file and convert it to a JSON file quickly in your browser for easy use in apps, APIs, and data workflows.
.xml file, click "Add Files," or paste raw XML directly into the input panel. The tool accepts well-formed XML with attributes, namespaces, CDATA sections, mixed content, and deeply nested elements. Batch upload of multiple files is supported..json file. Need the reverse direction? Use JSON to XML. For other transformations, see XML to YAML or JSON to CSV.XML dominated data interchange through the 2000s — SOAP web services, enterprise integration, HL7 healthcare, FpML finance, SVG graphics, RSS feeds, and OOXML documents all use it. JSON took over the API layer from the mid-2010s onward because it parses natively in JavaScript, has typed primitives (number, boolean, null) that XML lacks, and produces 30–50% smaller payloads for the same data. Most modernization projects start with an XML-to-JSON conversion step.
Codable), Android (Kotlin kotlinx.serialization), and every JS framework (React, Vue, Angular) ship JSON parsers in their standard library. XML requires extra dependencies and roughly 2–3x the parsing time on phone hardware.pandas.read_json() and Polars handle JSON in one line; XML needs xml.etree.ElementTree plus manual flattening. Converting upstream lets data scientists skip the boilerplate.| Property | XML | JSON |
|---|---|---|
| Year standardized | W3C Rec 1998 (XML 1.0) | ECMA-404 (2013), RFC 8259 (2017) |
| Syntax | Nested tagged elements | Key-value pairs and arrays |
| Native data types | All values are strings | string, number, boolean, null, object, array |
| Attributes on elements | Yes | No native concept |
| Namespaces | Full URI-based namespaces | Not supported |
| Comments | <!-- ... --> supported |
Not in the spec (JSON5/JSONC extend it) |
| Mixed content (text + child elements) | Supported | No clean representation |
| CDATA sections | Supported | Plain string |
| Schema language | XSD, DTD, RelaxNG | JSON Schema |
| Typical payload size | Larger (tags repeated, no native ints) | 30–50% smaller for the same data |
| MIME type | application/xml, text/xml |
application/json |
| Primary use today | SOAP, SVG, RSS, Office Open XML, legacy enterprise | REST APIs, configs, NoSQL, mobile, web |
XML-to-JSON conversion is intrinsically lossy because XML has features JSON cannot express directly. The table below summarizes how each tricky XML construct is typically represented in JSON.
| XML construct | Common JSON representation | Notes |
|---|---|---|
Element with text only — <title>Hello</title> |
"title": "Hello" |
Cleanest case |
Repeated siblings — <item>A</item><item>B</item> |
"item": ["A", "B"] |
Single occurrence becomes a string, not a 1-element array — known inconsistency |
Attribute — <price currency="USD">29.99</price> |
"price": {"@currency": "USD", "#text": "29.99"} |
@ prefix is the de-facto convention (Spark, Newtonsoft, xml2js); #text holds the body |
Namespace prefix — <soap:Body> |
"soap:Body": {...} |
Preserve to avoid collisions; strip for cleaner keys when there is only one namespace |
CDATA — <![CDATA[<script>...</script>]]> |
"key": "<script>...</script>" |
Wrapper drops; content preserved verbatim |
Mixed content — <p>Hello <b>world</b></p> |
{"p": {"#text": ["Hello ", ""], "b": "world"}} |
No canonical mapping; positional info often lost |
Comments — <!-- ... --> |
Dropped | JSON has no comment syntax (JSONC/JSON5 do, but not standard JSON) |
Processing instructions — <?xml-stylesheet ... ?> |
Dropped | Same as comments |
| DTD / XSD references | Dropped | Schemas are not embedded; validate with JSON Schema separately |
| Boolean / number values | String "true" or "42" unless type-coerced |
Some tools accept a _type hint to coerce to native types |
Most converters discard attributes by default to keep output keys clean. To preserve them, choose a mode that maps attributes to keys prefixed with @ (the convention used by xml2js, Spark, Newtonsoft, and the Badgerfish convention). For example, <user id="5">Alice</user> then becomes {"user": {"@id": "5", "#text": "Alice"}} rather than the lossy {"user": "Alice"}. If your XML relies on attributes (SVG, XHTML, SOAP, Atom), always enable attribute preservation.
JSON has no concept of namespaces, so namespace-qualified element names like <soap:Body> are either kept as literal keys ("soap:Body") or stripped to just the local name ("Body"). Stripping is convenient for single-namespace documents but causes silent key collisions when two namespaces define the same local name — for example, an XHTML <title> and an Atom <title> would overwrite each other. Preserve prefixes when working with SOAP envelopes, multi-vocabulary feeds, or anything from a WSDL-defined service.
This is the most common XML-to-JSON gotcha. <users><user>Alice</user></users> produces {"users": {"user": "Alice"}} — a string — while <users><user>Alice</user><user>Bob</user></users> produces {"users": {"user": ["Alice", "Bob"]}} — an array. The conversion is consistent given the XML, but downstream code that expects users.user.map(...) will crash on the single-element case. Either force specific elements to always be arrays (most production converters support this), or write client code that normalizes with Array.isArray(x) ? x : [x] before iterating.
By default, all XML text values are strings, because XML itself has no type system — <count>42</count> and <count>"42"</count> are indistinguishable. To get {"count": 42} rather than {"count": "42"}, the converter has to guess types or be told via a schema. Some tools support an inline _type hint or a JSON Schema annotation. If type safety matters, validate the JSON with a schema and coerce explicitly rather than relying on the converter to guess.
They are dropped. Standard JSON has no syntax for either, so converters silently strip <!-- ... --> comments and <?xml-stylesheet ... ?> style processing instructions. If your XML uses comments to carry configuration hints, version notes, or developer documentation, extract them with a separate pass before converting. JSON5 and JSONC support comments, but consumers expecting standard JSON will reject them.
CDATA wrappers are stripped and their content is emitted as a plain JSON string. <script><![CDATA[if (a < b) { return true; }]]></script> becomes {"script": "if (a < b) { return true; }"}. The < and & inside CDATA are JSON-escaped automatically — JSON string escaping handles them safely. The explicit "do not parse as markup" signal is lost, which only matters if a downstream consumer was specifically looking for it (rare).
Not without a convention. JSON cannot represent every XML construct natively, so any round trip XML → JSON → XML depends on the mapping conventions used. Conventions like Badgerfish and JsonML are designed for round-trip fidelity, but they produce verbose JSON that does not look like idiomatic data ("attribute namespaces become arrays of arrays"). For most real projects the goal is one-way: take the data fields out of XML and represent them naturally in JSON, accepting that comments, processing instructions, and exact whitespace will not survive.
Yes — the conversion happens in your browser, so the practical ceiling is your device's RAM. Most modern laptops handle 50–100 MB of XML without trouble; phones get sluggish above ~20 MB. For multi-gigabyte files (full Wikipedia dumps, SEC EDGAR archives, OpenStreetMap planet files), use a streaming command-line tool like xq, jq with xml2json, or a SAX/StAX parser in code — loading the whole tree into memory will fail regardless of converter.
No. The XML-to-JSON converter runs entirely client-side in your browser using JavaScript. Your file is read into memory locally, parsed, and the JSON is built and rendered without any network request carrying your content. This matters for SOAP envelopes containing PII, HL7 healthcare messages under HIPAA, FpML or FIX financial data, or anything else where uploading to a third-party server is not an option.
Direction. Use this page to take XML data and produce JSON for use in modern REST APIs, mobile apps, or NoSQL stores. Use JSON to XML for the reverse — for example, when an existing JSON API needs to feed a SOAP service or a legacy XML-based enterprise system. Round-tripping XML → JSON → XML may not return the byte-identical original because of comment loss, namespace handling, and attribute representation, so test the round trip if it matters.