XML to JSON
Parse any XML document into JSON. Repeated sibling elements become arrays, attributes and text values are preserved, and invalid XML is reported before
Parse an XML document into JSON: repeated sibling elements become arrays, attributes and text content are preserved, and invalid XML is reported with the position of the problem before any conversion happens.
Useful when an API or an export gives you XML but the rest of your tooling speaks JSON - a SOAP response, a data feed, a configuration export. Attributes are kept alongside child elements so nothing is dropped, and the structure is easy to map into your own schema afterwards.
How to convert XML to JSON
Paste your XML
Convert it and review the structure
Copy or download the JSON
FAQ
How are repeated elements handled?
Siblings with the same tag name become an array, whatever their count, so a list of one element still parses as a list rather than a single object.
What happens to attributes?
They are preserved as properties next to the element content, so nothing is lost. Adjust the naming in your mapping step if your schema expects a separate attributes object.
Can I keep the original order of elements?
JSON objects are unordered by definition, so element order is not guaranteed. If order is semantically important, keep the source XML as the reference.
Why was my XML rejected?
Common causes are unclosed tags, an undeclared namespace prefix, or stray text before the XML declaration. The error message points at the position where parsing failed.
Does it support CDATA and namespaces?
CDATA sections are read as text and namespace prefixes are kept as part of the element names, which is usually what you want for a faithful mapping.
Is my XML uploaded?
No, parsing happens locally in your browser.
At a glance
| Input | XML |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.