Why XML to JSON Looks Wrong (Attributes, Text, and Arrays of One)

The happy-path clicks are How to convert XML to JSON for modern apps. Format comparison is JSON vs XML vs YAML vs CSV. This page is the incident after the paste: what the shape means, what you lost, and how to inspect it without uploading a SOAP dump.

DevOkk’s XML to JSON runs in the browser. No account. Completing the convert does not require sending the document to DevOkk. The page still loads; analytics are in the privacy policy. A cloud “XML converter” that wants the file in a bucket is a different architecture. Customer SOAP belongs in the local tab or in a tool your contract names.

XML can say things JSON cannot

An element can have:

• Attributes (id="x")
• Child elements
• Text mixed between children (<p>see <em>this</em> now</p>)
• Namespaces
• Comments and processing instructions
• Repeated sibling names (<item> five times)

JSON has objects, arrays, strings, numbers, booleans, null. No attributes. No comments. One root value. Something has to give.

Converters typically:

• Turn attributes into keys (@id or _attributes.id)
• Put character data in #text or _ when it is not the only child
• Wrap repeated names in arrays
• Drop comments
• Flatten or discard namespaces

None of that is a bug in JSON. It is a projection. If your downstream code expected record.id as a child element and the converter put @id on the parent, you will swear the converter “lost the id.” It moved it.

A worked example: one record vs a list

XML:

<items>
  <item id="1">alpha</item>
</items>

A heuristic converter may emit { "items": { "item": { "@id": "1", "#text": "alpha" } } } - object.

Add a second <item> and the same converter emits "item": [ {...}, {...} ] - array.

Your JavaScript items.item.map explodes on the single-record payload. The XML was valid both times. Normalize: always array-ify item after convert, or fix the producer to always send a list wrapper. JSON Viewer makes the object-vs-array jump obvious. JSON Formatter pretty-prints so you can see it without squinting.

This is the most common “the API lied” ticket that was actually a converter convention.

Attributes vs child elements

<user id="9"><id>9</id></user> is legal XML and a nightmare projection. You get @id and id or a collision. The document author used two channels for the same fact. JSON cannot host both without a naming scheme. Pick the channel you mean in the source, or map explicitly in code. Do not keep re-converting hoping the keys get prettier.

Empty attributes (flag="") become empty strings. Missing attributes become missing keys. Downstream if (obj.flag) is a different boolean than XML’s “attribute present.”

Mixed content and #text

HTML-as-XML (<note>Pay <b>now</b> please</note>) produces a tree with text nodes and element nodes interleaved. JSON converters smash that into #text fragments or a child array. For a SOAP string field with no markup, #text means “the element had attributes too, so the character data could not be the whole value.”

If you only needed the string, you may want to extract text in the XML layer (XPath) rather than convert the whole envelope. Converting a 40-element SOAP wrapper to JSON so you can read one field is how you inherit forty conventions.

Namespaces and prefixes

xmlns:ns="..." and <ns:Price> survive as "ns:Price" or get stripped. Two vocabularies with a local name id collide if you strip prefixes. Feeds (Atom, RSS with extensions) live here. If the JSON lost which id you meant, you dropped the namespace. Keep XML for interchange; convert only the payload you own.

Numbers, booleans, and “it quoted 01”

XML text is text. 01, true, and 1e2 may stay strings. JSON numbers drop leading zeros. A converter that “helpfully” types true as boolean will break a field that was the string "true" in a vendor schema. Inspect types in JSON Viewer. Do not round-trip through JSON if leading zeros are the business key (some invoice numbers, some codes).

CSV has the same typing fight. Why CSV to JSON keeps failing if the source was a spreadsheet, not XML.

Encoding, BOM, and truncated envelopes

UTF-16 SOAP from an old Windows stack, a UTF-8 BOM, or a copy that starts at <Body> without the envelope - converters fail or emit garbage. Paste the document, not the log line INFO soap=. If the result is not JSON, you never left XML-parse failure. How to fix invalid JSON is for when you already have JSON-shaped text.

Entities (&) should become & in text nodes. Double-encoded & is a producer bug. The converter is not being clever.

Arrays of one, empty elements, and nil

<item/> vs <item></item> vs <item xsi:nil="true"/> vs omitted item are four XML states. JSON may map them all to null, {}, "", or missing. Your schema may care. Check a known empty case before you write production mapping.

What you cannot get back

Comments documenting a field, attribute order, CDATA vs escaped text, default namespaces, and DTDs. JSON will not carry them. If a regulator wants the original XML, archive the XML. Converted JSON is for apps.

“Pretty XML” whitespace in mixed content can become extra #text nodes of newlines. Trim or parse with a policy that ignores insignificant whitespace.

Cloud XML converters vs the tab

A 20 MB export with patient IDs should not go to a format-matrix site. Are online PDF converters safe? is the same architecture question with a different extension. XML to JSON locally, then JSON Formatter. If the file is too large for the tab, split it on disk or use a scripted parser you run yourself. Size is not a reason to upload PHI.

What not to paste into online developer tools applies to SOAP as much as to JWTs.

After it looks “right”

Minify only if you need bytes: JSON Minifier. Graph only if you are lost in nesting: JSON to Graph Visualizer. Neither will restore XML semantics. Write the mapping in code: “@id → id, always array item.” Tests with one-child and many-child fixtures.

YAML configs are a different converter: How to convert YAML to JSON. Do not XML-convert a YAML file.

A worked example: RSS item

<item><title>Hi</title><link>https://example.com/a</link></item> becomes a flat object. Add <category>news</category><category>local</category> and category becomes an array. Your reader that did item.category.toUpperCase() works until the second category ships. The convert did not regress. The XML gained a repeating sibling. Normalize categories to an array in one helper.

When not to convert at all

XSLT, XPath, or a SOAP library already speak XML. Converting to JSON to “use fetch” and then wrestling #text is extra surface. Convert when the consumer is JSON-only (a React fixture, a mock server, a colleague who refuses XML). Keep the source.

SOAP envelopes vs the payload you wanted

A full envelope is Header + Body + faults. Converting the envelope produces JSON about Envelope and Body before you ever see GetInvoiceResult. If you only needed the result, extract that element first (or use the SOAP client). Dumping the envelope is how #text and namespaces multiply.

MTOM / attachments are not XML text. A converter will not turn a PDF binary into a JSON field you can read. Keep the attachment as a file; convert the XML metadata only.

DTDs, XXE, and why a random uploader is a bad parser

External entity tricks belong in a security review of servers that parse XML, not in a how-to for attackers. For you: do not paste untrusted XML into a cloud converter that will parse it on a server. A local tab still parses; treat mystery XML like mystery files. Prefer documents you produced.

Attributes, text nodes, and arrays of one

Those three are the usual “wrong JSON.” They are the document model leaking through. XML to JSON is the local projection. JSON Formatter and JSON Viewer are how you see @, #text, and object-vs-array before you write the mapper. The original XML is still the record if you need fidelity. JSON is what you agreed to lose.