What Disappears When You Convert XML to JSON — Order and Whitespace in Mixed Content
If you've converted an RSS feed or an old document-style XML to JSON and the result came out oddly mangled, that's not the converter being broken — it's because XML and JSON can express fundamentally different structures. This guide explains, structurally, why and how the XML-specific concept of "mixed content" loses information in the process of becoming JSON.
1. A concept JSON doesn't have: mixed content
XML was born as a document markup language, so it naturally allows text and child tags to be interleaved in order within one element, as in <p>Hello <b>world</b>!</p>. This structure is called "mixed content." JSON, by contrast, was designed from the start for data serialization, so an object is just a set of key-value pairs. The concept "this text fragment, this child element, that text fragment sit side by side in exactly this order" doesn't exist in the JSON object model. So any XML-to-JSON converter, on encountering mixed content, has no choice but to decide to discard information.
2. How this tool actually handles it
This site's XML to JSON converter recursively walks elements, and when it hits a child text node it trims leading/trailing whitespace with node.nodeValue.trim() and appends it as-is to the existing #text value. Child elements (tags) are collected separately under their own keys. So the original order in which text fragments and child elements were interleaved is completely discarded, and text is reassembled with text, tags with tags, each into its own group.
<p>Hello <b>world</b>!</p> into this tool and you get{"#text":"Hello!","b":"world"}.The space that was between "Hello" and "!" is gone (joined into "Hello!"), and there's no way from this JSON alone to know that "world" was originally between "Hello" and "!".
3. The exact reason whitespace disappears
The culprit is calling trim() individually per text node. An XML parser splits <p>Hello <b>world</b>!</p> into three child nodes — text node "Hello " (trailing space included), element node <b>world</b>, text node "!". The converter trims each text node separately, so the trailing space of "Hello " is cut to "Hello", and this value joins the following "!" node with no space between them. In pure data XML (config files, API responses) the whitespace between tags is just indentation formatting and harmless to remove, but in document-style XML that whitespace actually carries the meaning of separating words when read, so removing it distorts the content.
4. Kinds of XML where this problem is especially visible
This shows up prominently in cases like an RSS/Atom feed's <description> field where HTML tags are mixed into the text, SVG text elements, and document-style markup like DocBook. Conversely, "data-style" XML like config files or API responses where each element holds only pure text or only child elements and never mixes them doesn't produce mixed content in the first place, so it's unaffected.
5. Practical guide
- Data-style XML like API responses and config files: convert with confidence. The element structure of holding only text or only children means no mixed content arises.
- RSS description, fields with HTML fragments mixed in: always eyeball the result after conversion. Especially if there were inline tags (
<b>,<a>) between text, whitespace/order loss is likely. - If you must preserve the document structure as-is: don't convert to JSON — handle it in XML/HTML form. JSON wasn't designed for this.
Frequently Asked Questions
Q. Does non-mixed-content, ordinary XML have this problem too?
A. No. In a "pure content" structure where an element holds only text or only child elements and never mixes them, there's just one text fragment, so the order/whitespace loss problem doesn't arise. It only happens when text and child tags alternate inside one element.
Q. Do CDATA sections have the same problem?
A. Yes. CDATA content is extracted as #text like ordinary text, so if CDATA is mixed inside mixed content, the same order/whitespace loss applies.
Q. Is there any way to prevent this loss?
A. To fully prevent it, the converter would have to be redesigned to give each child node an order index and not trim text nodes — which makes the output JSON much more complex (an array-based ordered node list, etc.) and loses the convenience of "simple JSON." Most lightweight converters choose to accept this loss for practicality.
Q. Conversely, does JSON to XML conversion not have this problem?
A. JSON to XML doesn't have this specific loss because JSON has no mixed-content concept to begin with, but it has other kinds of structural limitations like array representation and null handling. See the JSON to XML conversion guide for details.