JSON ⇄ XML Converter

An array keeps its JSON key as a wrapper, carries data-json-type="array", and contains one <item> child per value. An empty array is a marked self-closing wrapper. The marker is what distinguishes an empty array from an empty object and a one-item array from an ordinary element, so XML generated here restores the same array shape when converted back. A different system will only understand that meaning if it accepts this published convention.

Each attribute becomes a JSON key prefixed with @, so id="42" becomes @id: "42". Element text is kept under #text when an object is needed for attributes or children. XML attribute values always return as strings; JSON-to-XML accepts string, number or boolean attribute values, but a numeric attribute cannot announce that original JSON type on the way back. A null attribute is rejected instead of being turned into an empty string.

Unmarked XML has no way to say that 42 is a JSON number rather than two text characters, so its leaf values deliberately remain strings. XML generated from JSON here marks numbers and booleans with data-json-type, and the reverse conversion restores those types; null, arrays and objects are marked for the same reason. Do not add those reserved markers casually to outside XML, because an invalid marker shape is rejected instead of guessed.

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.

First check whether the receiving system accepts this tool's data-json-type and <item> convention; valid XML is not automatically valid against someone else's schema. Generated element and attribute names are validated here: they must start with a letter or underscore, use only letters, numbers, dots, hyphens or underscores, and cannot begin with xml. Rename an invalid JSON key before converting. If the receiver merely requires an XML declaration, turn on the declaration checkbox.

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.

The conversion stops. A namespace binds a name to a URI, and dropping that URI or keeping only the prefix would change the document's meaning. Any namespace declaration, namespace prefix or colon-qualified name is rejected with a direct explanation; use a schema-aware mapper that knows the expected URIs.