Gera Tools

XML to JSON Converter

Convert XML documents into clean, structured JSON.

Free XML to JSON converter that parses XML in your browser and produces clean, indented JSON with attributes and repeated tags handled correctly. Nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

How are attributes and repeated tags handled?

Element attributes are collected under an "@attributes" object, and when a tag appears more than once it becomes an array. A leaf element with only text becomes a plain string value.

Convert XML to JSON in your browser

Paste a well-formed XML document and get clean, indented JSON. This is the tool you reach for when an API or legacy system speaks XML but your JavaScript, config tooling or REST client wants JSON — feeds, SOAP responses, sitemaps and export files all convert in one step.

The mapping rules, and why there is no single standard

Parsing uses the browser’s native DOMParser, the same engine that reads real web documents, so behaviour matches how a browser interprets your markup. The tool then walks the resulting DOM tree recursively with a deterministic convention:

  • Attributes on an element are collected into an @attributes object.
  • A child tag name that appears more than once becomes a JSON array.
  • A leaf element with only text and no attributes becomes a plain string.
  • An element with both attributes and text keeps the text under a #text key.

If DOMParser injects a parsererror node — its signal for malformed input — the tool reports a clear error rather than emitting a half-broken object.

Example

Input:

<order id="1001" paid="true">
  <customer>Gera Tools</customer>
  <items>
    <item>Pliers</item>
    <item>Wrench</item>
  </items>
</order>

Output:

{
  "@attributes": { "id": "1001", "paid": "true" },
  "customer": "Gera Tools",
  "items": { "item": ["Pliers", "Wrench"] }
}

Note id/paid landed under @attributes, the single customer is a string, and the two <item> tags collapsed into an array.

Everything runs locally in your browser using the built-in DOMParser — your data is never uploaded or stored.

Common sources of XML that benefit from conversion

  • RSS and Atom feeds — the standard syndication formats are XML; parsing them as JSON makes them much easier to work with in JavaScript.
  • SOAP web service responses — older enterprise and government APIs still return SOAP envelopes; the conversion strips the XML shell and leaves the data.
  • Android resource files — strings.xml, layout XML, and AndroidManifest.xml are sometimes easier to inspect or diff as JSON.
  • Sitemaps — sitemap.xml files are well-structured XML that converts cleanly to a JSON array of URL objects.
  • Microsoft Office Open XML — .docx and .xlsx files are zipped XML; extracting and converting specific parts (like word/document.xml) can speed up custom processing.

What can go wrong and why

Repeated tags becoming arrays is the most common surprise. If a document sometimes has one <item> and sometimes has two, the JSON structure changes between the two cases — a single item is a string, two are an array. If you’re writing code that consumes this JSON, always check for Array.isArray(result.items.item) before iterating.

Attributes all become strings — DOMParser treats every attribute value as a string, so paid="true" becomes the string "true" in JSON, not the boolean true. If you need typed values, parse numeric and boolean attributes explicitly after conversion.

Mixed content (text nodes interleaved with child elements) is simplified. A <p>Hello <em>world</em></p> becomes an object with a #text for the prose parts, but the inline nature of the mix is not fully preserved. For document-oriented XML with inline markup, a specialised XSLT or DOM approach handles mixed content more faithfully than a generic JSON converter can.

The array problem — the conversion’s one genuine ambiguity

XML cannot distinguish “an element that happens to appear once” from “a list with one item”. <items><item>a</item></items> might mean a scalar or a one-element array, and the converter cannot know which until it sees a document where item repeats. This is the root cause of the classic downstream bug: code written against sample data where a node repeated (and was therefore an array) breaks on the production document where it appeared once (and became an object). Defensive consumers normalise — wrap single objects into arrays before iterating. The mismatch is structural: XML’s document model (attributes, namespaces, mixed content, ordering) is simply richer than JSON’s data model of objects, arrays and scalars defined in RFC 8259, so every converter chooses conventions (attribute prefixes, text-node keys) rather than following a standard — there is none. When you control the pipeline, document which converter’s convention you adopted; when you don’t, inspect the output shape for attributes and repeated elements before writing a line of consuming code. The XML side’s authoritative reference remains the W3C XML specification.

When the XML uses namespaces heavily (SOAP envelopes, RSS with extension modules), expect prefixed keys like soap:Body in the output and decide early whether to strip prefixes — consistent handling matters more than which convention you choose, because mixed handling breaks every JSONPath query downstream.

Attribute-versus-element style also varies wildly between XML producers — one API writes <price currency="USD">10</price>, another writes the currency as a child element — so two feeds carrying identical information can convert to structurally different JSON. Normalising that shape is application logic, not conversion logic, and belongs in one documented mapping layer rather than scattered through consuming code.