XML to JSON Converter

XML to JSON Converter: Paste Markup, Get Code-Ready JSON

There is no JSON.parse() for XML. The instant you try to pull a few fields out of a SOAP response or an RSS feed in JavaScript, you are walking a DOM tree node by node, checking nodeType, and reading textContent off children that may or may not exist. This XML to JSON Converter collapses that whole chore into one paste. You drop in the markup, it parses every element, attribute, and nested child, and you get back valid, indented JSON you can address with plain dot notation: data.catalog.book[0].title.

It runs entirely in your browser, so conversion is instant and your XML never leaves the machine. No account, no upload, no daily cap. What follows is the part most converter pages skip — exactly what the output looks like for the structures you actually hit (attributes, repeated tags, mixed content, self-closing tags, CDATA), the edge cases that quietly break downstream code, and how to read the result so you write your consuming code against the right shape the first time.

A Worked Example: From Tags to Curly Braces

The fastest way to see what the converter decides on your behalf is to feed it something real. Here is a small book catalog with the three features that make XML awkward — repeated tags, attributes on opening tags, and an element carrying both an attribute and a value:

<catalog><book id="42" inStock="true"><title>Dune</title><author>Frank Herbert</author><price currency="USD">19.99</price></book><book id="43" inStock="false"><title>Hyperion</title><author>Dan Simmons</author><price currency="USD">14.50</price></book></catalog>

Convert it and you get JSON that keeps every piece:

{ "catalog": { "book": [ { "@id": "42", "@inStock": "true", "title": "Dune", "author": "Frank Herbert", "price": { "@currency": "USD", "#text": "19.99" } }, { "@id": "43", "@inStock": "false", "title": "Hyperion", "author": "Dan Simmons", "price": { "@currency": "USD", "#text": "14.50" } } ] } }

Three decisions happened automatically. The two book elements collapsed into an array, because a list of records is an array. Attributes were kept and prefixed with @ so they can never collide with a child element of the same name. And price, which had both a currency attribute and the number 19.99 inside it, kept both — the attribute under @currency, the value under #text. One detail to internalize now: "#text": "19.99" is a string, not a number. XML has no type system, so the converter cannot know whether 19.99 is a price, a version label, or a part code. If you need arithmetic, cast it yourself with parseFloat().

How to Convert XML to JSON

The whole thing takes a few seconds, with nothing to install or configure.

1. Add your XML. Paste markup into the input box, or upload an .xml file. A two-line snippet and a ten-thousand-line export are handled identically.
2. Press Convert. The tool walks the entire element tree, capturing tag names, attributes, text, and nesting, and builds the equivalent JSON object.
3. Read the output. The JSON appears indented in a results panel. Keys map to your tag names, attributes carry their @ prefix, and the nesting mirrors your original hierarchy.
4. Copy or download. Send the JSON to your clipboard, or save it as a .json file ready for a codebase, an API mock, or a database import.

Because the engine runs locally, there is no queue and no server round-trip. Changed source? Clear the box, paste the new version, convert again — repeat as many times as you need.

The Four Structural Mismatches, Resolved

XML and JSON disagree about structure in exactly four places. Knowing how each one resolves lets you predict the output shape before you write a single line against it.

Attributes become prefixed keys, never dropped

JSON has no notion of an attribute — everything is a key. So <user role="admin" active="true"> becomes an object with "@role": "admin" and "@active": "true" sitting alongside its child elements. This matters more than it first appears: in a large share of real XML, the attributes hold the load-bearing metadata — record IDs, type discriminators, units, currency codes, status flags. A converter that silently discarded them would corrupt your data without erroring. Every attribute survives here, and the @ prefix is what guarantees <type id="x"><id>y</id></type> produces both @id and id without one clobbering the other.

Repeated tags become an array — but a lone tag does not

When a parent holds several siblings with the same tag name — five <item> tags, twenty <entry> tags in a feed — the converter emits a JSON array, which is exactly what you loop over. The trap is the single-element case: a tag that appears once converts to a bare object, not a one-element array. So a feed with one <item> gives you "item": { ... } while a feed with two gives you "item": [ {...}, {...} ]. Your code then does data.item.map(...) in testing, ships, and throws map is not a function the day a real feed arrives with a single entry. Defend against it before you iterate:

const items = Array.isArray(data.rss.channel.item) ? data.rss.channel.item : [data.rss.channel.item];

This one quirk is the single most common "worked on the test file, broke in production" bug with any XML-to-JSON conversion. Normalize once, at the boundary, and forget about it.

Deep nesting carries through intact

A two-level document and a twenty-level document both keep their full parent-child relationships — nothing is flattened. The indented output is often easier to scan than the source XML, where matching open and close tags blur together across dozens of lines. If you only need one buried value, the JSON path is shorter to read than counting indentation in the original.

Text, mixed content, and empty tags

An element holding only text becomes a plain string. An element holding both attributes and text keeps both, with the text under #text (the price case above). Self-closing and empty tags resolve predictably too: <br/> or <tag></tag> typically becomes an empty string or empty object rather than vanishing, so a missing-looking key in your output usually means an empty element in the source, not a dropped one. Genuinely mixed content — text interleaved between child elements inside the same parent — is rare in data XML and is where any converter must make pragmatic choices; inspect the output if your source has it.

CDATA and Comments: What Happens to Them

Two XML features have no JSON equivalent, so it is worth knowing the behavior up front. CDATA sections — the <![CDATA[ ... ]]> wrapper used to embed raw HTML or markup without escaping it — are unwrapped: the content inside becomes an ordinary string value, which is almost always what you want, since the CDATA wrapper was only ever an escaping mechanism. A WordPress export, for instance, wraps post bodies in CDATA, and after conversion you simply get the HTML as a string you can render or sanitize. XML comments (<!-- ... -->) carry no data and have no place to live in JSON, so they are dropped — do not rely on a comment surviving the conversion as a marker. If your pipeline genuinely needs comment text, extract it from the source before converting.

Where This Earns Its Keep

JSON is the lingua franca of the modern web, but an enormous amount of valuable data still ships as XML. The concrete situations where converting pays off:

• Taming a SOAP or legacy enterprise API. Older services return XML envelopes. With a React, Vue, or vanilla front end, converting the payload lets you read native objects instead of fighting a DOM parser for every field.
• Reshaping feeds and sitemaps. RSS, Atom, and XML sitemaps convert cleanly — each <item> or <url> becomes an array element ready to render or store. (Watch the single-item array quirk on small feeds.)
• Skimming config files. A Maven pom.xml, an Android layout, or a Spring beans file is far easier to scan as indented JSON when you are documenting a system or hunting one buried setting.
• Prototyping a document-DB import. MongoDB and similar stores ingest JSON natively. Converting first lets you preview the record shape before you write an importer.
• Previewing an integration mapping. Before wiring a transform step in SAP CPI, MuleSoft, or any middleware, converting a sample shows the exact JSON shape you will map to — saving a round of trial and error.
• Learning the formats side by side. Seeing the same data as both tags and curly braces is one of the fastest ways to internalize how each represents structure.

For conversions inside a running app, reach for code — Python's xmltodict, a Java library, or an npm package runs unattended in a pipeline. This tool is for the one-off: when you want to see the shape right now without spinning up an environment. Most developers use both — the browser to check the shape, a library in production.

Getting Clean Output

A converter is only as good as the XML handed to it. Most "the tool is broken" reports are really the source document. These habits keep the output clean:

• Confirm the XML is well-formed. Every opening tag needs a matching close, and the whole document needs exactly one root element. An unbalanced tag is the number-one cause of a failed conversion.
• Escape special characters in text. A raw & or < inside element text breaks parsing — they must be written & and <.
• Save as UTF-8. An exotic encoding or a missing declaration can garble characters; re-saving as UTF-8 fixes most of them.
• Plan your types. Remember every value arrives as a string. Decide where you will cast numbers, booleans, and dates before you build logic on the output.
• Indent while developing, minify for production. The pretty-printed output is for reading; strip whitespace when payload size matters.

The conversion fails or returns nothing

Almost always malformed XML. Confirm every tag is closed, that a single root element wraps everything, and that special characters are escaped. Scan from the top for the first unbalanced tag — fixing the source fixes the conversion nearly every time. Running the source through an XML Formatter first will surface the break point.

My attributes seem to be missing

They are present, prefixed with @ on the element that owned them — so look for @id, not id. If you still cannot find one, confirm it was a valid attribute inside an opening tag and not stray text the parser ignored.

I got one giant array when I wanted named objects

Your XML has many sibling elements sharing a tag name, which correctly becomes an array — that is the intended behavior for lists. If you need distinct named keys, the source has to use distinct tag names rather than repeating one.

The JSON looks correct but my code cannot read it

Validate the output, then check you are reading the exact key names and nesting the converter produced — including the @ attribute prefix and the single-element array quirk. A mismatched key or an assumed array is the usual culprit, not the conversion itself.

XML vs JSON, Briefly

Both store structured, hierarchical data; they just say it differently. XML wraps every value in a matched pair of named tags, allows attributes on those tags, and adds machinery JSON lacks — namespaces, comments, and XSD schemas for validation. That power is why it still dominates publishing, finance, and government systems. JSON expresses the same data with key-value pairs, arrays, and a few primitive types; it is more compact and maps directly onto native data structures in nearly every language, which is why web APIs adopted it. The one structural mismatch the converter has to resolve is that XML separates attributes from child elements and JSON does not — so it folds attributes into prefixed keys in a consistent, predictable way, exactly as the examples above show.

Related Tools on Tools Hub

If the XML to JSON Converter is useful, these free Tools Hub utilities pair naturally with it:

• JSON to XML Converter — go the other direction and turn JSON back into well-formed XML.
• JSON Formatter — beautify, indent, and validate your converted JSON so it is easy to read and error-free.
• JSON to CSV Converter — flatten JSON into a spreadsheet-friendly table for analysis or import.
• CSV to JSON Converter — bring tabular data into the JSON world for apps and APIs.
• XML Formatter — clean up and indent messy XML before converting, which heads off conversion errors.
• Base64 Encoder / Decoder — handy when data payloads need encoding for safe transport.

Frequently Asked Questions

Is the XML to JSON Converter really free?

Yes, completely. There is no trial, no premium tier that unlocks the real features, and no hidden charge. Convert as many files as you want, as often as you want.

Do I have to create an account or sign up?

No sign-up. You do not enter an email, create a password, or log in — open the page and start converting. There is no account system to collect your information.

Is my data safe? Is anything uploaded?

The conversion runs entirely in your browser, so your XML is never uploaded, stored, or logged. That makes the tool safe for confidential or proprietary files. Close the tab and nothing about your file remains.

Will the converter add a watermark or modify my output?

No. The JSON you get is clean, standard, valid JSON with no watermark, no inserted comments, and no promotional text — just your XML faithfully translated and ready to use.

How does it handle attributes?

Each attribute becomes a key prefixed with @ on its element, kept distinct from child elements so the two never collide. Nothing is dropped, which matters because XML attributes so often carry the IDs, types, units, and status flags you most need.

Why did one element convert to an object instead of an array?

A tag that appears once converts to a single object; a tag that repeats among its siblings converts to an array. If your code always expects an array, normalize with Array.isArray(x) ? x : [x] before iterating, since the same tag can yield either shape depending on how many times it appears.

Are values converted to numbers and booleans?

No — every value comes back as a string, because XML carries no type information. A price of 19.99 arrives as "19.99" and true arrives as "true". Cast values yourself (parseFloat, a boolean check) wherever your logic needs a real number or boolean.

What happens to CDATA sections and comments?

CDATA is unwrapped — the content inside <![CDATA[ ... ]]> becomes an ordinary string value, which is usually what you want. XML comments carry no data and are dropped, so do not rely on a comment surviving the conversion.

What if my XML has namespaces?

JSON has no native concept of namespaces, so the converter focuses on faithfully translating your elements, attributes, and text. If a workflow depends heavily on namespaces, review the output and align your downstream code with how they appear.

Does it handle invalid or partial XML?

It expects well-formed XML — balanced tags and a single root element. If your XML is incomplete or malformed, fix the structure first, since valid input is what guarantees valid JSON output. An XML Formatter helps spot the problem before converting.

Is there a limit on file size or number of conversions?

There is no enforced daily limit and no artificial cap. Because processing happens locally, the practical ceiling is your device's memory, which comfortably handles the vast majority of real-world XML documents.