XML ⇄ JSON Converter

Because JSON object keys have no concept of an attribute, while XML attributes and child elements are genuinely different things that need distinguishing. Using @id for an attribute and id for a child element is the most widely used convention and requires no non-standard extensions. If the system you integrate with uses a different convention (a - prefix, say) you can change it here; and if the attributes are pure metadata you can discard them altogether.

Because the NameStartChar character class in the XML specification does not include non-ASCII characters such as Chinese, so a Chinese tag name is genuinely invalid XML. This was confirmed against Python’s xml.etree, which reports "not well-formed (invalid token)". An early version of this tool let such names through and was changed to reject them — a parser more permissive than the reference implementation is the dangerous kind, because it makes you believe your XML is valid right up until you feed it to another system. If your data really does contain non-ASCII tag names it is probably not standard XML (some bespoke format, perhaps) and needs converting first.

Because an element has two shapes that need different representations. An element with neither attributes nor children contains only text, so a bare string is cleanest (<name>Tom</name> → "Tom"). One with attributes or children needs an object to hold multiple keys. This is controlled by the "collapse text" option; turning it off makes every element an object so the structure is uniform.

By default it becomes an array, because that is the only lossless representation. But if an element is logically singular in your data and happens to appear twice once, automatic array conversion catches downstream code off guard. Hence the "forced arrays" option: list the element names and they are always arrays, so consumers never need a compatibility branch for "sometimes an object, sometimes an array".

Comments are dropped during conversion. JSON has no comment syntax, so there is nowhere to put them; and comments are typically notes for humans, which would pollute the data structure if carried across. If you need to compare files including comments, that is a text comparison task rather than a format conversion.

Because expanding a custom entity means parsing ENTITY declarations inside DOCTYPE, which is the classic entry point for XML External Entity (XXE) attacks — they can be used to read files from the server. This tool handles only the five language built-ins and numeric character references. Anything it cannot recognise is **preserved verbatim** and listed for you, rather than silently dropped or speculatively expanded. That is both safer and means you never lose data without knowing.

Structurally, yes: XML converted to JSON and back restores the hierarchy, attributes and text. Two kinds of information are lost, however: comments, and insignificant indentation whitespace between elements (preserving it would add a pile of empty #text nodes to every formatted document). So a round trip is semantically equivalent but not byte-identical. For byte-level comparison use a text diff tool instead.

Prefixes are preserved as written: <ns:root xmlns:ns="urn:x"> yields the JSON key ns:root. This differs from Python’s etree, which expands it to {urn:x}root. The choice is deliberate — people using a toolbox generally want to see the shape of their XML, and long URI prefixes make that harder rather than easier. The difference is documented on the page; if you need rigorously expanded namespaces, use a dedicated programming library.