XML to JSON Converter

1. 1

   Add your XML

   Paste the markup into the editor, or drop a file onto the page. XML, SVG, RSS, Atom, WSDL, XSD, KML, GPX, plist and OPML are all accepted, and the character encoding is detected from the byte-order mark or the XML declaration.

2. 2

   Pick an output shape

   Compact is the familiar shape most tools produce. BadgerFish and GData are the two conventions used by long-running APIs. Parker gives the plainest possible values. JsonML keeps document order and round-trips exactly.

3. 3

   Set how values are read

   Decide whether attributes are kept and what prefixes their keys, whether lone elements become one-item arrays, what an empty element becomes, and whether numbers and booleans are inferred rather than left as text. The preview updates as you change each one.

4. 4

   Convert, then download or copy

   Press Convert to write the file. Choose 2 spaces, 4 spaces, tabs or minified output, then download the .json or copy it. With Pro you can convert up to 50 files at once and take them away as a single ZIP.

Most XML to JSON converters make one silent decision on your behalf and give you no way to change it: they pick a shape, drop your attributes, and hand back JSON that looks right. This one asks. You choose the output convention, whether attributes survive and what prefixes them, whether a lone element is a value or a one-item array, what an empty element means, and what happens to namespace prefixes — and the preview beside the controls shows the answer as you change each one.

• Nothing is dropped — Attributes, CDATA sections, mixed text and processing instructions all survive the conversion. Each one has a control, so you decide what to keep rather than discovering afterwards what was lost.
• Five output shapes — Compact, BadgerFish, GData, Parker and JsonML. Four are the conventions real APIs use; JsonML is the one that keeps document order and converts back exactly.
• Errors you can act on — A failed parse gives the line, the column, the source line and a caret under the offending character, with a message that names the fault rather than restating that the file is invalid.
• Big files stay smooth — Reading and writing happen away from the interface, so the page never freezes. A 25 MB document converts in about a second with a progress bar and a Cancel that works.

There is no single correct way to represent XML as JSON, which is why several conventions exist and why serious libraries let you choose. XML has attributes, ordered children, mixed text and namespaces; JSON has objects, arrays and strings. Every mapping trades one of those away. Picking the right trade for what you are doing next is most of the work.

• Compact — the default — Elements become keys, attributes are prefixed with @_ and text sits under #text. This is the shape most tools and most tutorials produce, so it is the one that will look familiar to whoever reads the file next. Choose it unless you have a reason not to.
• BadgerFish — uniform — Every element is an object, text always sits under $, attributes under @name and namespace declarations under @xmlns. Nothing is ever a bare string, so code consuming it never has to test whether a field came back as an object or a value. Verbose, and predictable in exchange.
• GData — Google's shape — Attributes become plain keys alongside child elements and text sits under $t. Compact to read, and the right choice when you are matching an existing Google Data or Atom feed shape.
• Parker — the plainest — Attributes are discarded, the root element's name is dropped and leaves become their values. The result is the closest thing to what you would have written by hand if you had started in JSON. Use it for configuration and simple data where attributes carry nothing you need.
• JsonML — lossless — Each element becomes an array of its tag name, its attributes and its children in document order. It is the only shape here that survives a round trip, and the only one that can represent an element, then a different element, then the first element again.

An XML element carries three different things at once — its attributes, its text, and its child elements — and a JSON object has one namespace of keys for all three. Every convention resolves that collision differently, and the collision is real: an element with an attribute called name and a child element called name needs both to survive.

• The attribute prefix — @_ by default, and configurable. Its only job is to keep an attribute's key from colliding with a child element of the same name, so any prefix that does not appear in your tag names works. Set it to an empty string if you know there are no collisions and want the flattest output.
• The text key — #text by default. It is used when an element has both text and something else — attributes, child elements, or both. An element with nothing but text is written as that text directly, so simple documents stay simple.
• Mixed content — A paragraph containing a bold run has text before, inside and after its children. That text is collected and kept under the text key rather than discarded, which means a document you would describe as prose rather than data still converts to something you can read.
• Whitespace — Text is trimmed by default, because indentation in a pretty-printed XML file is layout and not data. Collapse reduces every run of whitespace to a single space; None keeps the text exactly as written, which is what you want for anything whose formatting matters, like embedded code.

The single most common surprise in XML to JSON conversion is that the shape of the output depends on the number of records in the input. One order in the file gives you an object; two gives you an array. Code written against a sample with two orders then breaks on the day a customer sends one, and the failure looks like bad data rather than an ambiguous mapping.

• Repeated (default) — A tag appearing several times as siblings becomes an array, preserving order and count. A tag appearing once stays a single value. This is what almost every converter does, and it is the most readable output.
• Always — Every element that could repeat becomes an array, even with one occurrence. The output is slightly more verbose and completely predictable, which is what you want when the JSON is going straight into code rather than being read by a person.
• Order across different tags — Arrays keep the order of same-named siblings, but no key-based shape can keep the order of different ones — an object's keys carry no sequence. If the interleaving matters, JsonML is the shape that keeps it.

Namespaces are the reason enterprise XML looks the way it does, and they are where a naive converter quietly produces something wrong. A prefix such as soap: is not part of the element's name — it is a pointer to a URI declared somewhere above it, and the same prefix can mean different things in different parts of one document.

• Keep — Prefixes stay exactly as written, so soap:Envelope stays soap:Envelope and the JSON matches the document you are looking at. This is the right default for SOAP responses and WSDL, where the prefixes are what everyone refers to.
• Strip — Prefixes are removed for a cleaner, shorter shape. Two elements from different namespaces can then land on the same key, which is real information loss — so when it happens, the tool counts the collisions and tells you rather than letting the merge pass silently.
• Expand — Each prefix is replaced by its full namespace URI in braces. Nothing is ambiguous and nothing can collide, at the cost of long keys. This is the shape to pick when the JSON is being validated or compared rather than read.
• Unprefixed attributes — An attribute with no prefix is in no namespace at all — it does not inherit the element's default namespace. That is a rule converters routinely get wrong, and getting it wrong invents a namespace the document never declared.

XML has no types. Every value in a document is text, and any converter that hands you a number has decided on your behalf that the text looked numeric enough. That decision is useful often and destructive occasionally, which is why it is a control here and why it is off until you turn it on.

• What converts — Plain integers and decimals, true, false and null. Nothing else.
• What deliberately does not — A value with leading zeros stays text, because an order number written 007 is not 7. A leading plus stays text, because a phone prefix is not a number. A value beyond the safe integer range stays text, because converting it would silently change the digits. So does anything written in exponent or hexadecimal notation, and so do Infinity and NaN, which a naive numeric conversion accepts and no XML document means.
• The round-trip rule — A value only becomes a number if writing that number back out gives exactly the characters that were in the file. That is what protects 1.0, which most converters turn into 1 and hand back as though nothing happened.
• Empty elements — An empty element can reasonably be an empty string, a null or an empty object, and which one is right depends on what you are doing next. Rather than pick for you it is a control, so a nillable field and a genuinely blank one can be told apart.

Broken XML is the normal case, not the exception, and it is usually broken for one of about six reasons. A converter that answers with the word Invalid has told you nothing you did not know; what you need is the character that caused it.

• The line, the column and a caret — Every failure reports where it happened, shows the source line and puts a caret under the exact character. Long single-line documents are windowed around the fault so a minified file does not print itself into the error box.
• An unescaped ampersand — The most common fault in hand-written XML. A bare & in Q&A or in a URL query string is not valid markup and must be written &. The message says so rather than reporting a mysterious entity error.
• Tags that do not match — A start tag closed with a different name, or a tag left open at the end of the file. Both name the tag involved, and the unclosed case points at where the element was opened rather than at the end of the document.
• Namespaces and duplicates — A prefix used without being declared, or the same attribute written twice on one element. Both are errors rather than quiet merges, because silently keeping one of two values puts data in your output that nobody wrote.
• Entities and DTDs — A DOCTYPE is parsed and skipped rather than followed. Declared entities are recognised by name but never expanded, so a reference to one is reported clearly instead of being substituted — which is also what makes the classic entity-expansion attack impossible here.

Everything below is XML, and every one of them was a file the previous version of this page would let you choose and then do nothing with, because it only recognised the .xml extension while the operating system reports no type at all for most of the rest.

• Feeds and syndication — RSS and Atom, including the item and entry sets that make the most useful newline-delimited output. OPML for subscription lists.
• Web services — WSDL service definitions and XSD schemas, both of which are namespace-heavy and are the reason the Keep namespace policy is the default.
• Graphics and geography — SVG documents, where converting to JSON is how a path or a viewBox gets read by a build script. KML and GPX for map data and recorded tracks.
• Configuration and documents — Apple plist property lists, .config and .csproj build files, Maven POM files, XSLT stylesheets and XHTML.

The document is read and written away from the interface, so the page stays responsive while a large file converts, with real progress and a Cancel that takes effect immediately.

• Output shape — Compact, BadgerFish, GData, Parker or JsonML. Changes the whole structure; the preview updates immediately.
• Attributes — Keep or drop them, and set the prefix their keys carry. Ignored in Parker, which drops attributes by definition.
• Text key — The key holding an element's own text when it also has attributes or children.
• Arrays — Repeated elements only, or force an array for every repeatable element.
• Namespaces — Keep the prefix, strip it, or expand it to the full URI.
• Types — Leave every value as text, or infer numbers, booleans and null with the round-trip rule applied.
• Empty elements — An empty string, a null, or an empty object.
• Whitespace — Trim, collapse runs to one space, or keep the text exactly as written.
• CDATA — Merge into the element's text, or keep it under its own key.
• Comments and instructions — Dropped by default; keep either when you need them, which only the order-preserving shapes can express fully.
• Indent — 2 spaces, 4 spaces, tabs, or minified onto one line.
• Encoding — Detected from the byte-order mark or the XML declaration, and overridable when a file declares the wrong one.

XML is still where a great deal of real data lives — bank statements, government feeds, SOAP services, build files, map exports and every RSS feed ever published — while almost everything built to consume data now expects JSON. Converting is usually the shortest path between the two, and it only stays short if the conversion does not lose anything on the way.

• Legacy services into modern code — A SOAP response becomes something a fetch call can read without an XML library in the bundle.
• Feeds into pipelines — An RSS or Atom feed becomes a record set, and with newline-delimited output it becomes something a data tool can stream.
• Configuration into tooling — A plist, a POM or a .config file becomes readable to a script that has no XML parser.
• Inspection — A deeply nested document is easier to read as JSON in an editor that folds it, which is often the real reason for converting at all.
• It stays private — Bank statements and service responses are exactly the documents nobody should paste into a website that uploads them. This one does not upload.

• JSON to XML
• JSON Formatter
• JSON Validator
• JSON Viewer
• YAML to JSON
• JSON Minifier