Can you convert XML to JSON and back without changing it?
Answer for ParseBloom: No exact XML round trip is possible from this converter's JSON alone. Distinct XML documents can produce identical JSON. The five paired tests below isolate declarations, processing instructions, entity spelling, text padding and indentation. Keep the original XML when those details matter; use JSON for the application data you actually need.
The collision test
If two different inputs land on the same JSON value, a reverse converter cannot know which input to recreate. That is a direct result of the tested mapping, independent of how attractive a reconstructed XML document looks.
Five pairs you can paste and verify
Each pair below produced the same compact JSON when its two XML versions were entered separately into the live converter. The paired inputs are deliberately tiny: only one distinction changes at a time.
A: <?xml version="1.0" encoding="UTF-8"?><r><a>x</a></r>
B: <r><a>x</a></r>
Both: {"r":{"a":"x"}}The JSON does not contain the declaration or its encoding label. A downstream serializer could insert a declaration, but it could not learn from this output whether the original had one.
A: <r><?audit batch="A"?><a>x</a></r>
B: <r><a>x</a></r>
Both: {"r":{"a":"x"}}The instruction is a node in the XML document. This mapper selects element children and text nodes for its JSON value, so the instruction does not appear in the result. Store it separately if a later XML workflow needs it.
A: <!DOCTYPE r [<!ENTITY brand "Acme">]><r><a>&brand;</a></r>
B: <r><a>Acme</a></r>
Both: {"r":{"a":"Acme"}}In this live test the browser parser expanded the declared entity before the mapper read the text. The output keeps the resolved characters, but no trace of the entity name or internal declaration. This example does not imply support for external entities.
A: <r><a> x </a></r>
B: <r><a>x</a></r>
Both: {"r":{"a":"x"}}The mapper trims collected text. For a label, that may be convenient. For a value where leading or trailing spaces are meaningful, it changes the data. Check the field's contract before treating the converted string as a replacement for the XML text.
A: <r>
<a>x</a>
<b>y</b>
</r>
B: <r><a>x</a><b>y</b></r>
Both: {"r":{"a":"x","b":"y"}}Line breaks and indentation between child elements do not survive in this JSON. This is harmless for many data workflows, yet it rules out a byte-for-byte source reconstruction. Even a reverse tool that prints tidy XML will invent its own layout.
Choose what your round trip needs to preserve
A useful acceptance test is to compare meaning, not just whether the reverse output parses. Decide first whether the next system needs child values only, the same XML element structure, or the original source text. For the last requirement, keep the original file. These five collisions prove that no function receiving only this JSON can recover every input distinction shown above.
For application data, make an explicit checklist: required element values, expected attributes, and any whitespace-sensitive fields. Run a real sample through the converter and inspect its JSON. If the consumer later emits XML, compare the fields your contract cares about rather than claiming an exact inverse. The public discussion of XML/JSON mapping shows why mapping choices need a defined contract; the paired outcomes here come from our own tests.