Page & Bell

XML ⇄ JSON Converter

Convert XML to JSON and JSON back to XML entirely in your browser — nothing you paste ever leaves your machine, which matters when the payload is a SOAP response, an RSS feed, or a config file with credentials in it. Unlike converters that hide their mapping, the exact rules this tool applies are printed below: how attributes become keys, when repeated elements become arrays, what happens to CDATA, and which constructs are inherently lossy. Parse errors surface with the browser's own message and location, so a stray unclosed tag on line 200 takes seconds to find, not minutes.

How to use the xml ⇄ json converter

  1. Pick a direction: XML → JSON or JSON → XML.
  2. Paste your document into the input box.
  3. For XML → JSON, choose an attribute prefix (@ by default) and toggle force-arrays if your schema needs stable array shapes.
  4. For JSON → XML, optionally name the root element and pick an indent style.
  5. Click Convert, review any lossiness warnings, and copy the result.

The exact mapping rules this converter applies

XML constructJSON result
Attribute sku="A1"Key "@sku": "A1" (prefix selectable: @, _, or none)
Element with only textThe text string becomes the value directly
Element with text plus attributes/childrenText stored under "#text"; mixed content triggers a lossiness warning
Repeated sibling elements (same name)Array; a single occurrence stays an object unless force-arrays is on
Empty elementnull
CDATA sectionPreserved as plain text in the string value
Namespaced element soap:BodyKey keeps the prefix: "soap:Body"
Whitespace-only text nodesTrimmed away by default (toggle to keep)
Comments, processing instructionsDropped (JSON has no equivalent)

Going JSON → XML, the rules invert: keys beginning with @ become attributes, #text becomes element text, arrays expand into repeated elements, and scalar values are escaped (ampersand, angle brackets, and quotes in attributes) so the output is always well-formed. A single-key root object is used as the document root automatically; anything else is wrapped in the root element name you supply.

Where this conversion shows up in real work

Three workflows account for most XML↔JSON traffic. First, legacy SOAP and enterprise APIs: you receive an envelope hundreds of lines deep and want to explore it as JSON in a REPL or pipe it through jq-style tooling. Second, RSS and Atom feeds: a feed item's mix of elements (title, link, pubDate) and namespaced extensions (media:content, dc:creator) maps cleanly once you know attributes carry the @ prefix. Third, configuration migration: Maven POMs, Android manifests, and old .NET config files are XML, while modern tooling wants JSON or YAML — convert here, then hand-check the spots flagged by warnings. For the reverse direction, some government and banking APIs still demand XML request bodies, and building them from a JSON template with @-attributes is far less error-prone than string concatenation.

Worked example

Input XML with one attribute, a repeated element, and plain text:

<order id="42">
  <item sku="A1">Widget</item>
  <item sku="B2">Gadget</item>
  <note>Rush delivery</note>
</order>

Output with the default @ prefix:

{
  "order": {
    "@id": "42",
    "item": [
      { "@sku": "A1", "#text": "Widget" },
      { "@sku": "B2", "#text": "Gadget" }
    ],
    "note": "Rush delivery"
  }
}

Note the asymmetry: item became an array because it repeats, while note collapsed to a plain string because it has no attributes or children. Feed this JSON back through JSON → XML and you get the original document back (minus insignificant whitespace).

Frequently asked questions

Why do single elements become objects but repeated elements become arrays?

XML has no array syntax — repetition is implied by sibling elements with the same name. The converter maps two or more same-named siblings to a JSON array, but a single occurrence stays a plain object because there is no way to know the schema allows repetition. If your downstream code expects item to always be an array (even with one item), enable the force-arrays toggle, which wraps every child element in an array for a stable shape.

Is XML to JSON conversion lossless?

No, and any tool claiming otherwise is glossing over real losses. JSON object keys are unordered, so the relative order of differently-named XML siblings is not guaranteed; comments and processing instructions are dropped; mixed content (text interleaved with child elements, common in HTML-like XML) loses the position of the text; and the attribute-versus-element distinction only survives if you keep the @ prefix. This tool flags mixed content with a warning instead of silently mangling it.

How are XML attributes represented in the JSON output?

Each attribute becomes a key prefixed with @ by default, so <item sku="A1"> becomes { "@sku": "A1" }. You can switch the prefix to _ (some Java libraries expect this) or to none, but the no-prefix option risks collisions: an element with both an attribute id and a child element id would overwrite one with the other. The @ prefix is what allows JSON → XML to reconstruct attributes.

What does the #text key mean in the output?

When an element carries only text, the text becomes the value directly: <name>Asha</name> turns into "name": "Asha". But when an element has attributes or child elements and text, the text needs its own slot, so it lands under "#text". Going the other way, a "#text" key in your JSON is emitted as the element’s text content.

What happens to CDATA sections and namespaces?

CDATA content is treated as ordinary text and preserved verbatim in the JSON string value — the CDATA wrapper itself is a serialization detail and is not kept. Namespace prefixes stay in the key names (soap:Envelope becomes the key soap:Envelope), which keeps SOAP and RSS extensions readable; the xmlns declaration attributes are carried over as attribute keys too.

Why did my conversion fail with a parsererror message?

The tool uses the browser's strict XML parser (DOMParser), which rejects anything that is not well-formed: unclosed tags, unescaped ampersands (& must be &amp; in XML), attribute values without quotes, or multiple root elements. The error message shown is the parser's own and usually includes a line and column number. HTML is not XML — pasting an HTML page will often fail on void tags like <br> unless they are self-closed.

Related tools

Learn more