XML to JSON Converter

Start with the mapping, not the syntax

XML and JSON can represent the same business facts, but they do not share one canonical data model. XML has elements, attributes, ordered child nodes, namespaces, text, and mixed content. JSON has objects, arrays, member names, and primitive values. An XML to JSON converter must therefore choose a mapping policy rather than perform a lossless change of punctuation.

This converter makes that policy visible. You can choose the prefix attached to attribute names, choose the member name used for text alongside attributes or child elements, omit attributes, and decide whether repeated sibling elements become arrays. Input is parsed by the browser’s XML DOMParser; malformed XML clears the output and displays the parser’s error. Successful JSON is pretty-printed with two-space indentation and can be copied or downloaded.

One document, several mapping decisions

Use this sample inventory:

<inventory region="west">
  <item sku="A-10">Cable</item>
  <item sku="B-20">Adapter</item>
  <available>true</available>
  <count>2</count>
</inventory>

With the defaults, Attribute Prefix @, Text Node Key #text, attributes included, and repeated elements merged, the online XML to JSON converter emits:

{
  "inventory": {
    "@region": "west",
    "item": [
      {
        "@sku": "A-10",
        "#text": "Cable"
      },
      {
        "@sku": "B-20",
        "#text": "Adapter"
      }
    ],
    "available": true,
    "count": 2
  }
}

The root element always becomes the outer JSON member. A leaf element with no attributes becomes a primitive directly. A leaf with attributes becomes an object; its character data is placed under the selected text key. Repeated child names at one parent become an array when merging is enabled.

Configure the shape before integrating it

Attribute Prefix

XML allows an attribute and child element to share a local spelling. Prefixing attributes reduces JSON member collisions and communicates their origin. The default turns sku="A-10" into "@sku": "A-10". Enter _ to produce _sku, or another string required by your application. An empty prefix is allowed by the field, but it increases collision risk: an attribute and a child with the same name write to the same object key during conversion.

Text Node Key

The default #text is used when text must coexist with attributes or element children. You may replace it with $, _text, value, or another consumer convention. As with the attribute prefix, choose a key that cannot collide with a generated child name.

Ignore XML attributes

Selecting this option excludes every attribute from the output. A leaf that previously needed an object may then collapse to a primitive. This can simplify a payload when attributes are known metadata, but it is destructive. IDs, language declarations, units, namespace declarations, and status flags commonly live in attributes. Confirm that none are required before enabling it.

Merge elements into arrays

Enabled by default, this groups repeated siblings of the same node name. Without it, each later sibling overwrites the earlier value under that name. In the inventory example, disabling merging leaves only the second item. The option does not create an array for a name that occurs once, so consumers still need to account for a scalar-or-array shape when source cardinality varies.

Primitive coercion deserves a deliberate review

Element text and attribute values pass through a small primitive parser. Exact lowercase true, false, and null become their JSON counterparts. Any nonempty string accepted by JavaScript’s Number conversion becomes a number. Everything else remains a string.

That convenience can alter identifiers:

<record code="0012">
  <postal>02110</postal>
  <enabled>True</enabled>
  <empty></empty>
</record>

The codes 0012 and 02110 become numbers, losing leading zeroes. True remains a string because matching is case-sensitive. An empty leaf becomes an empty string. There is no “keep all values as strings” option, so inspect account numbers, SKUs, phone fragments, precision-sensitive decimals, and notation such as exponential values before adopting output.

What happens to XML node types

Element children are converted recursively. Text nodes and CDATA section nodes are concatenated, then their combined text is trimmed. Comments and processing instructions are not included in the object. The converter retains element nodeName values, including prefixes, but it does not expand namespace URIs into a separate JSON representation.

When an element has both child elements and non-whitespace text, that text is stored using the configured text key. This preserves a flattened text fragment, but not the original ordering between text and child nodes. Consider:

<p>Read <em>this</em> first.</p>

The output object has an em member and a #text value formed from “Read ” and “ first.” after concatenation and trimming. It cannot express that the emphasized element occurred between those text segments. Mixed-content publishing formats therefore cannot round-trip through this mapping faithfully.

A migration workflow that catches surprises

1. Obtain a representative XML sample containing optional attributes, empty elements, repeated siblings, CDATA, and maximum expected nesting.
2. Paste it into XML Input and resolve any parser error before considering mapping options.
3. Establish attribute and text-key names that match the destination API’s contract.
4. Keep array merging enabled when repeated data must survive; test both one-item and multi-item documents.
5. Toggle attribute omission only after cataloging what each attribute carries.
6. Inspect every converted number and boolean for unwanted coercion.
7. Compare mixed-content and namespace-heavy sections against the source.
8. Copy the JSON for an immediate test or download converted.json with the application/json media type.
9. Validate the result against the destination’s JSON Schema or runtime model.

Conversion updates after every input or option change. Clear resets input, output, and errors. Copy and Download are disabled when parsing fails or no output exists. This makes the page suitable for interactive experiments without implying that the chosen shape is automatically correct for an API.

Failures and how to read them

The browser XML parser rejects malformed markup, including mismatched tags and documents without a usable root element. Its diagnostic text appears in the XML header area and may differ by browser. Repair the XML source rather than editing generated JSON, because output remains empty until parsing succeeds.

A successful parse only establishes XML well-formedness as recognized by DOMParser. It does not validate a DTD, XSD, or business vocabulary. External entity behavior, schema defaults, ID constraints, and XSD datatypes are outside the conversion. If schema processing would supply default attributes or normalize values, perform that processing in an appropriate XML pipeline before conversion.

Good uses for a free online XML to JSON converter

This page is practical for adapting a small legacy API response to a JavaScript test fixture, understanding the shape of a SOAP payload, prototyping an ingestion mapping, or converting a configuration fragment for discussion. The explicit controls help document assumptions that are often hidden inside library defaults.

For bulk files, streaming feeds, signed XML, or a production migration, encode the mapping in tested code. A repeatable converter should fix its namespace strategy, cardinality rules, numeric policy, error handling, and schema validation. Browser experimentation is valuable for designing those rules; it is not a substitute for implementing them.

Questions about the generated JSON

Why is a single element not an array?

Array merging only changes a member after a second sibling with the same name appears. One occurrence remains a single value. Test varying cardinality before defining consumer types.

What happens when array merging is off?

Repeated names overwrite earlier values at the same parent. Only the last converted sibling remains under that key.

Can I retain 00123 as a string?

Not through an option on this page. Numeric-looking values are coerced with JavaScript number conversion. Quote conventions in XML do not change that because all attribute and text values arrive as strings before coercion.

Are CDATA sections supported?

Their character data is accumulated with ordinary text-node content. The CDATA wrapper itself is not represented in JSON.

Are comments converted?

No. The traversal processes element, text, and CDATA nodes for values; XML comments do not appear in output.

Does it resolve namespaces?

No. Qualified nodeName and attribute names are used as encountered. Namespace URIs and prefix scopes are not emitted as a dedicated model.

Is conversion reversible?

Not generally. Comments, processing instructions, node ordering in mixed content, lexical number forms, and sometimes repeated values can be lost. Treat the JSON as a selected projection of the XML.