XML to JSON mapping guide

Can XML namespaces survive a JSON conversion?

Answer for ParseBloom: The converter keeps a qualified name such as a:item as a JSON key and stores an xmlns:a declaration under _attributes. It does not turn each name into a namespace URI plus local name. Two prefixes for the same URI therefore become different keys; the same prefix can also mean different URIs in nested scopes. Do not use the JSON key alone as namespace identity.

Seven synthetic inputs tested in the live ParseBloom XML to JSON converter, 28 October 2026. This is a contract for this mapper, not every XML-to-JSON tool.

One URI, two JSON keys

The diagram is a warning about interpreting the output, not a promise of a reversible namespace mapping. The exact input and output are in case 5 below.

Seven copyable namespace probes

Paste each input into the converter and press Convert to JSON. The results below are compacted from the live browser output. The first pair changes only the prefix. The later cases isolate default namespaces, attribute placement, and a declaration that changes meaning inside one subtree.

1 · Prefix a

<r xmlns:a="urn:one"><a:item>A</a:item></r>

{"r":{"_attributes":{"xmlns:a":"urn:one"},"a:item":"A"}}

The declaration is retained as an attribute entry; the child key uses its literal qualified name.

2 · Same URI, prefix x

<r xmlns:x="urn:one"><x:item>A</x:item></r>

{"r":{"_attributes":{"xmlns:x":"urn:one"},"x:item":"A"}}

The namespace URI and value match case 1, but a consumer asking for r['a:item'] will not find the child.

3 · Default namespace

<r xmlns="urn:one"><item>A</item></r>

{"r":{"_attributes":{"xmlns":"urn:one"},"item":"A"}}

There is no prefix on the child key. Its declaration still exists in the root's attribute object.

4 · Namespaced child with a plain attribute

<r xmlns:a="urn:one"><a:item code="7"/></r>

{"r":{"_attributes":{"xmlns:a":"urn:one"},"a:item":{"_attributes":{"code":"7"}}}}

The child keeps a:item; its own unprefixed code attribute remains a plain string. Attribute and element names must be interpreted separately.

5 · Two prefixes, one URI

<r xmlns:a="urn:one" xmlns:x="urn:one"><a:item>A</a:item><x:item>B</x:item></r>

{"r":{"_attributes":{"xmlns:a":"urn:one","xmlns:x":"urn:one"},"a:item":"A","x:item":"B"}}

The two children do not become one repeated-name array. Their JSON keys differ even though both declarations point at the same URI.

6 · Same prefix, different URIs by scope

<r xmlns:a="urn:one"><a:item>A</a:item><group xmlns:a="urn:two"><a:item>B</a:item></group></r>

{"r":{"_attributes":{"xmlns:a":"urn:one"},"a:item":"A","group":{"_attributes":{"xmlns:a":"urn:two"},"a:item":"B"}}}}

The same key spelling appears at two levels, but the nearest declaration gives it a different namespace URI. A flattened list of keys loses that distinction.

7 · Two prefixes, two URIs

<r xmlns:a="urn:one" xmlns:b="urn:two"><a:item>A</a:item><b:item>B</b:item></r>

{"r":{"_attributes":{"xmlns:a":"urn:one","xmlns:b":"urn:two"},"a:item":"A","b:item":"B"}}

This output happens to separate the two XML names by prefix. That is not a substitute for resolving their declarations when schema meaning matters.

What a consumer should check

Choose a stable rule before sending this JSON into a database or comparing records from two XML producers. If exact namespace identity matters, resolve the prefix against the declarations in scope while you still have the XML DOM. Then use the pair namespaceURI and localName for matching. A generic JSON object does not carry that pair as a first-class field in this converter.

Boundary: These tests show the declarations in _attributes and the qualified element names in property keys. They do not show that every XML namespace detail is reconstructed automatically. Renaming a prefix may change the JSON shape without changing the expanded XML name; moving a declaration may change the expanded XML name without changing the short key you inspect.

A quick pre-migration check is to paste the same small document twice, changing only a prefix while keeping its URI. Compare both outputs. If downstream code treats them as unrelated records, resolve namespaces before that code sees JSON. If your input format guarantees one fixed prefix convention, document that narrower contract instead of assuming it holds for arbitrary XML.

The JSON Checker converter page says it handles namespaces, while the CodeShack converter exposes other mapping options and the JSON Formatter converter page emphasizes its tool interface. Those pages do not establish this mapper's output; the copyable probes do. A public question about XML namespaces in JSON is one example of the practical concern.

For separate shape issues, see one versus repeated children and attributes and text-like IDs. Test your own XML locally