XML to JSON Converter

XML still runs a large part of the web behind the scenes: RSS and Atom feeds, XML sitemaps, SOAP web services, product feeds, invoices and configuration files. Most modern code, though, would rather work with JSON. Our free XML to JSON converter turns one into the other in both directions, right in your browser. You choose how attributes and text are named, whether repeated elements always become arrays, whether namespace prefixes are kept, and whether numbers and true or false values become real JSON types. Going the other way, you set the root and array item element names, add an XML declaration and pick the indentation. Parse errors show the line and column where your browser reports them, and nothing you paste is uploaded.

How to use the XML to JSON

1. 1 Choose a directionPick XML → JSON or JSON → XML at the top. Swap direction sends the current result back to the input, which is a quick way to see how well a round trip holds up.
2. 2 Paste, open a file or load a samplePaste your data, open an .xml or .json file from your device, or load one of the samples: an RSS feed, a sitemap snippet, a SOAP envelope, a product feed or a plain JSON array.
3. 3 Set the mapping optionsKeep the default @ prefix for attributes and #text for element text, or change them to match the code that will read the result. For XML input, choose how repeated elements, namespaces, CDATA and comments are handled.
4. 4 Fix any errorsIf the input is not well-formed XML or valid JSON, the error box shows the message, the line and column, and the lines around it. Show in editor selects the line for you.
5. 5 Copy or downloadCopy the result to your clipboard or download it as converted.json or converted.xml. Read any notes under the result, because they tell you what the conversion could not keep.

Why there is no single correct XML to JSON mapping

XML and JSON look like two spellings of the same idea, but their data models differ in ways that matter. XML has elements, attributes, text, CDATA sections, comments, processing instructions and namespaces, and the order of child elements is significant. JSON has objects, arrays, strings, numbers, booleans and null, and nothing else. An attribute and a child element can carry the same information in XML, while JSON has only one kind of key.

Because of this, every converter has to make choices, and different libraries make different ones. Some put attributes under an @ prefix, some under a nested object, some mix them in with child elements. Some always produce arrays, some only when an element repeats. No standards body has settled on one mapping, so the same XML can produce several valid JSON shapes, and none of them is the official answer.

This tool uses a widely used convention: attributes become keys that start with a prefix, element text that sits next to attributes or child elements goes under a text key, and repeated elements become arrays. Every part of that convention can be changed with the options, so you can match the format another system already expects. What you should not expect is a perfect round trip. Converting XML to JSON and back can reorder attributes, drop comments and processing instructions, and change how mixed text is laid out. If byte-for-byte fidelity matters, keep the original XML.

How elements, attributes and text are converted

The root element becomes the single top-level key of the JSON object. An element that contains only text, with no attributes and no children, becomes a plain value, so a title element holding Hello becomes "title": "Hello". An empty element with no attributes becomes null.

As soon as an element has attributes or child elements, it becomes an object. Each attribute becomes a key made from the prefix and the attribute name, such as "@id". Child elements become keys named after the element. Any text alongside them goes under the text key, which defaults to #text. That is how a price element with a currency attribute and a value of 12.50 becomes an object with "@currency" and "#text" keys.

• Attribute prefix: the default @ keeps attributes apart from child elements. You can use another prefix such as an underscore or a dash. Leaving it empty mixes attributes with child elements, and they can no longer be told apart when you convert back.
• Text key: #text is common, but some systems expect _text, $t or value. Change it to whatever the receiving code reads.
• Repeated elements: in the default mode an element becomes an array only when it appears more than once. Always an array wraps every child element in an array, which gives you the same shape whether a feed has one item or fifty.
• Numbers and booleans: XML has no data types, so everything starts as text. With type conversion switched on, values such as 42, 3.5 and true become JSON numbers and booleans. Values that would change when converted, such as 007, 1.0 or very long digit strings, are left as text so nothing is silently lost.

Arrays, auto-detection and why consistent shapes matter

Auto-array mode gives you the most compact JSON, but it has a well-known trap. An RSS feed with two item elements produces an array, while the same feed with one item produces a single object. Code that loops over the items works on Tuesday and breaks on Wednesday when only one post is published. For anything that runs automatically, such as a feed importer or an integration that reads a partner's XML, Always an array is the safer choice, because the shape stays the same however many elements there are.

Order is another thing to keep in mind. JSON objects do not promise any key order, although most parsers keep insertion order in practice. If the order of different child elements carries meaning, for example in a document format where paragraphs and images alternate, a key-based mapping cannot represent it, and the converter warns you when it finds text mixed with child elements. Data-oriented XML, such as feeds, sitemaps, API responses and configuration, converts cleanly. Document-oriented XML, such as XHTML or word processor files, usually does not.

Namespaces, CDATA and comments

Namespaces let one document mix vocabularies, such as Dublin Core inside RSS, image extensions inside a sitemap, or the SOAP envelope around a web service payload. By default the converter keeps prefixes in key names, such as "dc:creator", and keeps xmlns declarations as attribute keys, which lets you convert back to equivalent XML. Choosing Strip prefixes and xmlns gives shorter, friendlier keys like "creator", but elements from different namespaces that share a local name are then merged, so only strip namespaces when you know that cannot happen in your data.

CDATA sections hold text that would otherwise need escaping, such as HTML inside a feed description. Treat as text merges their content into the normal text value, which is what most consumers want. Keep under "#cdata" preserves them as a separate key, and the JSON to XML direction writes that key back as a CDATA section, splitting any ]]> sequence safely. Comments are dropped by default because most JSON consumers have no use for them. Switch on Keep comments to collect them under a #comment key. Processing instructions and the DOCTYPE are not carried into the JSON.

Converting JSON to XML

The JSON to XML direction applies the same convention in reverse. Keys that start with the attribute prefix and hold a simple value become attributes, the text key becomes element text, #cdata becomes a CDATA section, #comment becomes an XML comment, and every other key becomes a child element. An array becomes repeated elements with the key's name, which is exactly how a list of product elements is written in XML.

XML needs exactly one root element, while JSON does not. If your JSON is an object with a single key, that key becomes the root. Otherwise the converter wraps everything in the root element name you choose. A top-level array is wrapped in the root element, and each entry uses the array item element name, which defaults to item. Arrays nested directly inside other arrays get the same item wrapper.

JSON keys can contain spaces, start with a digit or be empty, none of which is allowed in an XML element name. Those keys are renamed, for example first name becomes first_name and 1x becomes _1x, and the converter lists each rename so you can check it. Special characters in values are escaped, control characters that XML 1.0 does not allow are removed, and the finished XML is parsed once more to confirm it is well-formed. The most common reason it would not be is a key with a namespace prefix, such as soap:Body, without a matching @xmlns:soap attribute.

Errors, large files and privacy

XML is parsed by your browser's built-in DOMParser and JSON by the browser's own JSON parser, so there is nothing to install and nothing leaves your device. When XML is not well-formed, the browser reports the line and column where it noticed the problem, which may be just after the real mistake, such as a missing closing tag several lines earlier. Different browsers word their messages differently, and not every browser gives a position for every error. For JSON, the converter finds the position itself when the browser does not give one.

Files of a few megabytes convert in a second or two on a typical laptop. The preview shows the first 300,000 characters to keep the page responsive, while Copy and Download always include the full result. Files over 10 MB are refused when opened, because a browser tab is not the right place for very large data. For big exports, a command-line tool or a streaming parser in your own code will be faster and more reliable.

If you only need to tidy or validate XML without converting it, the XML Formatter and Validator pretty-prints, minifies and tests XPath expressions. For other data formats, the JSON to YAML Converter handles configuration files, and the CSV to JSON Converter turns spreadsheets into JSON and back.

A note on XML security and external entities

XML can declare entities in a DOCTYPE, and an external entity can point at a file path or a URL. On a server, a parser that resolves those entities can be tricked into reading local files or making network requests on an attacker's behalf. This class of problem is known as XML external entity injection, or XXE, and it is why server-side XML parsers should have DTD processing and external entity resolution switched off unless they are truly needed. Nested entity definitions can also be used to expand a small file into an enormous one and exhaust memory.

This converter runs entirely in your browser, and browser XML parsers do not fetch external entities or external DTDs, so pasting a document that declares them does not make the page read files or contact other servers. Entities defined inside the document itself are expanded, and browsers apply their own limits to runaway expansion. That protects this page, but it says nothing about the system the XML came from or the one it is going to. If you are building an integration that accepts XML, check the security settings of the parser you use.

Examples you can copy

<order id="10482" status="shipped">
  <line sku="MUG-01" qty="2">Ceramic mug</line>
  <line sku="TEA-12" qty="1">Loose leaf tea</line>
  <note/>
</order>

{
  "order": {
    "@id": "10482",
    "@status": "shipped",
    "line": [
      { "@sku": "MUG-01", "@qty": "2", "#text": "Ceramic mug" },
      { "@sku": "TEA-12", "@qty": "1", "#text": "Loose leaf tea" }
    ],
    "note": null
  }
}

[{"name": "Austin", "country": "US"}, {"name": "Lyon", "country": "FR"}]

<?xml version="1.0" encoding="UTF-8"?>
<cities>
  <city>
    <name>Austin</name>
    <country>US</country>
  </city>
  <city>
    <name>Lyon</name>
    <country>FR</country>
  </city>
</cities>

Common mistakes to avoid

Frequently asked questions