XML to JSON Converter

XML never really went away, even though most new web development happens in JSON. Podcast feeds and blog RSS are XML. Sitemaps submitted to Google are XML. A lot of SOAP-based enterprise APIs — the kind still running inside banks, airlines, insurers, and government systems that were built fifteen or twenty years ago and are too load-bearing to rip out — speak nothing but XML. So does the export function on plenty of older line-of-business software: accounting packages, inventory systems, CMS platforms that predate the JSON era. If you’re building anything modern with that data — a React app, a script, a Node service — you almost always want JSON instead, because that’s the shape modern tooling expects and every JavaScript object already is. This tool sits in that gap: feed it an XML file and it hands back the equivalent JSON, structured, nested, and ready to use.

Why the two formats don’t map onto each other cleanly

The tricky part of XML-to-JSON conversion isn’t reading the file — it’s that XML can express things JSON has no direct equivalent for. A JSON object is just keys and values. An XML element, by contrast, can carry attributes on the opening tag itself, have text content, contain child elements, or do all three at once, and there’s no single obvious way to squeeze that into a plain JSON object without losing something. This converter makes a deliberate, consistent choice: attributes get placed under an @attributes key inside the corresponding object, so an element like a product tag with an id attribute ends up as an object containing both an @attributes section and its regular child fields, rather than the attribute silently vanishing or getting mixed in with everything else.

Repeated tags become arrays automatically

This is the detail that matters most in practice. In XML, a list is just the same tag repeated — three item elements one after another inside a channel, for instance, the way an RSS feed lists articles. JSON doesn’t have a native way to say “these are a list” just from repetition; it needs an actual array. The converter watches for this: the first time it sees a given tag name it stores it directly, but the moment a second sibling with the same name shows up, it upgrades that key into an array and keeps appending to it. Loose text content that sits alongside child elements or attributes — a common pattern in older XML — gets preserved too, tucked under a #text key so it isn’t silently dropped just because the element also had structure around it.

Where this actually comes up

A developer inheriting an old SOAP integration is a frequent case — the backend still only returns XML, but the new frontend is built entirely around JSON, and rather than writing a custom parser for one particular API’s XML shape, it’s faster to convert a sample response once and work from that. Someone migrating a blog or podcast off an old platform runs into it too: exporting the RSS feed and converting it to JSON makes it far easier to script a migration into a modern static site generator or headless CMS, most of which expect JSON content sources. SEO and technical audits are another one — pulling apart a sitemap.xml to check for duplicate URLs, missing lastmod dates, or oddities in a script is a lot more pleasant once it’s JSON you can loop over instead of raw markup you have to query with XPath. And plenty of people still just inherit a data export from an older enterprise system — a supplier catalog, an inventory feed, a customer list — that was clearly generated by software with no plans to ever touch JSON.

The parsing itself uses the browser, not a bundled library

Rather than shipping a custom XML parser, this tool hands your file to DOMParser, the XML-parsing engine already built into every modern browser for handling things like RSS readers and XML HTTP responses. That has a nice side effect: if your file isn’t well-formed XML — a tag left unclosed, mismatched nesting, an unescaped ampersand — the browser’s own parser catches it and the tool reports the file couldn’t be parsed rather than guessing at a broken structure and handing you something subtly wrong. It’s worth fixing the source file in that case rather than trying to force a conversion, since a parser error usually means the XML was already invalid before it ever reached this tool.

A couple of things to watch for

• Because repeated tags only become arrays once there are two or more of them, a feed with exactly one item today might convert to a single object rather than a one-item array — worth accounting for in any script that consumes the output, since the shape can shift depending on how many entries were present.
• The root element’s tag name is kept as the single top-level key wrapping everything else, matching the structure of the original document rather than flattening it away.
• Deeply nested XML — which is common in SOAP responses with several layers of wrapper elements — produces equally nested JSON. That’s accurate to the source, even if it means digging through a few layers to find the field you actually want.

All of this happens locally, in your browser tab, using the parser that’s already built into it — there’s no server involved, no XML data leaving your machine, and nothing to wait on beyond however long it takes your computer to walk the document. For a one-off conversion of a feed, an API sample, or an old export you need in a modern format, that’s about as low-friction as bridging two very different-looking data formats can get.