JSON ⇄ XML Converter

XML has no array type, so every convention fakes one with repeated sibling elements. One style writes a plural container holding singular children — a tags element with three tag elements inside. Another writes them bare with no container at all, which is the approach taken in the JSON to XML direction here. Both are valid XML and neither is recoverable on its own, because nothing in the document says whether a lone element is a list of one or an ordinary field. Agree the convention with whoever consumes the file before either side writes code against it.

They have to go somewhere, and JSON has no separate slot, so conventions invent one — usually a prefix such as an at sign on the key, with the element's own text under a reserved name. The alternative is to drop them, which is what the XML to JSON direction does here: the walker looks at element children and their text only, so an id or a lang written as an attribute disappears with no warning. Anything carrying real information in attributes — most configuration formats, and a lot of older enterprise XML — needs a mapper you have configured, not a generic pass.

Because XML has no types. Everything between two tags is text, and a document only knows that 42 is a number if a schema says so — which is what XSD is for, and a bare document does not carry it. Going out to XML here, a number is written as its text; coming back, every leaf is read as a string, so 42 returns as characters and true returns as a word. The case that bites is a reference with leading zeros, which survives fine as text and gets quietly mangled by anything eager to make it a number.

No. Both directions are ordinary functions called on the text already sitting in the box: JSON.parse and a recursive builder one way, the browser's built-in DOMParser and a walker the other. Nothing leaves the tab — no upload step, no server round trip, and nothing kept once you close it, since the input and result are component state and nothing else. That matters given what tends to get converted: API responses with customer records in them, payment feeds, config files listing internal hostnames. Switching direction empties both boxes on the spot as well.

Four causes cover nearly all of it. XML allows exactly one root element, so a fragment with two top-level tags is not a document and gets rejected. Tags are case-sensitive, so a closing tag capitalised differently closes nothing. A bare ampersand is illegal and has to be written as an entity, and the same goes for a less-than sign. And an entity HTML defines but XML does not — a non-breaking space is the usual culprit — fails unless the document declares it first. The message here is a flat invalid notice with no line number, so scanning for those four is quicker.

Most likely the tag names. XML element names cannot contain spaces, cannot begin with a digit or with punctuation other than an underscore, and cannot begin with the letters xml in any casing. JSON keys have none of those restrictions, so a key such as first name, or one starting with a year, produces a document no parser will accept — and nothing here checks a key before writing it out as a tag. Rename the offenders in the JSON first. The other complaint is a missing declaration line: none is written, so add it above the root yourself if the consumer insists.

JSON, in most cases where the choice is genuinely free — it is smaller on the wire, it maps onto the data structures of every mainstream language, and browsers parse it natively. XML earns its place where documents rather than objects are the point: mixed content where text and markup interleave, validation in XSD, signatures over part of a document, and namespaces that let two vocabularies share a file without collision. In practice the choice is rarely free. Finance, government, healthcare, publishing and anything speaking SOAP settled on XML long ago.

Nothing good, in a generic conversion. A namespace binds a prefix to a URI so that two vocabularies can use the same local name without ambiguity, and it is the URI that carries the meaning, not the prefix. JSON has no equivalent. Here the prefix survives as part of the key while the declaration that gave it meaning does not, leaving you a key with a colon in it and no record of what it pointed at. If namespaces matter to your document, keep the original beside whatever you convert and map it with something told which URIs to expect.