Convert JSON to XML

An XML document has a single outermost element. A JSON document may be an object with fifteen keys, or an array, or a bare number, and none of those come with a name for the container. So the conversion has a rule: an object with exactly one key uses that key as the root, and everything else is wrapped in an element called root. The exception is worth knowing because it catches one of the commonest shapes there is — if that single key holds an array, {"items": [1, 2]}, using it as the root would write <items> twice and produce a document with no outermost element, so <root> is wrapped around the pair instead.

The first case is the one to aim for, and it is a small edit to the JSON if you control it. Wrapping your payload in a single key named after what it is — invoice, order, shipment — means the XML comes out with the element name the receiving system is expecting instead of a generic wrapper you then have to rename in the output.

XML has no array type and never needed one: a list is the same tag written several times in the same parent. So an object holding three tags produces three <tags> elements in a row, which is exactly the shape every XML consumer already handles.

This is the one place where XML is a better fit for JSON than the tabular formats are. Converting the same array to CSV forces a choice between extra columns, a joined string and extra rows, and each of those is wrong for something. In XML the repetition is native, so an order with five line items converts without any decision having to be made on your behalf.

XML has two ways to attach a value to an element — an attribute inside the tag or a child element — and schemas care a great deal about which. JSON has one. The convention here bridges that: a key beginning with @ is written as an attribute, and a key called #text supplies the element’s own text alongside its children.

That convention is not arbitrary; it is what this site’s XML reader produces in the other direction. A document converted to JSON, edited and converted back returns the attributes as attributes rather than promoting them to elements, which is what makes a round trip through JSON a usable way to edit an XML payload. If the intake expects id as an attribute and your JSON has it as a plain key, renaming that key to @id before converting is the whole fix.

JSON keys can be any string at all: spaces, slashes, emoji, a leading digit, an empty string. XML element names cannot. The writer rewrites rather than fails, and it rewrites against a deliberately narrow list — A-Z, a-z, 0-9, underscore, dot and hyphen survive, everything else becomes an underscore, and a name starting with a digit gets one in front. So "2024 report" arrives as <_2024_report>.

The list is narrower than XML 1.0’s, and that is the case most likely to catch you: XML element names may contain accented letters, Greek, Cyrillic, Devanagari and CJK, and this writer keeps none of them. A key called café arrives as <caf_> and 名前 arrives as <__>, so a payload keyed in anything but ASCII loses the names rather than the values. The file is well-formed and the names are not the ones your schema declares. Rename those keys in the JSON, or restructure so the variable part is a value rather than a key, which is what the XML side was going to require anyway.

XML brings namespaces, XSD schemas, DTDs, processing instructions, CDATA sections and digital signatures — the registry lists signature support as one of its traits, and it is the reason the format is still the backbone of banking and government exchange. None of that can be derived from a JSON file, because none of it is expressed in one.

What that means in practice: the output is a well-formed document, not a valid one. If the intake validates against an XSD, expect to add a namespace declaration on the root element and possibly to reorder elements, since XSD sequence is order-sensitive and JSON object order is not meaningful. Both are edits to the output or to a small XSLT step, and both are far quicker once you have the document than they are theoretical.

Ampersands, angle brackets and double quotation marks in a value are escaped on the way out, which is what stops a product description containing "Tom & Jerry <special>" from ending the document early. Everything else, including apostrophes and every non-ASCII character, is written through as UTF-8.

A JSON null becomes an empty element: the tag is present with nothing between the opening and closing halves. That is a deliberate choice and it is not the only one available — XML also has xsi:nil for exactly this, and some schemas require it. If yours does, the empty elements are a search-and-replace away, and knowing which of the two your consumer expects is worth checking before the first delivery rather than after.

The document is written with two-space indentation and one element per line, which makes it readable and makes a diff between two payloads legible. It does not begin with the <?xml version="1.0"?> line. XML 1.0 makes the declaration optional and defines UTF-8 as the default encoding, so the file is well-formed without it.

A number of older intakes disagree, and some of them fail with an unhelpful message when the line is missing. It is one line to add at the top. Worth knowing before a first submission, because "the file is invalid" from a middleware queue rarely tells you which of the twenty possible things it means.

Every value is wrapped in an opening and a closing tag, so the field names appear twice per record instead of once. For a payload of small values with long field names the document can be two to three times the size of the JSON it came from, and the indentation adds to that.

That is a real cost on a queue with a message size limit and no cost at all on a file transfer, which is where most of these deliveries actually go. Where it does matter, the answer is compression rather than restructuring — XML is highly repetitive text and gzips extremely well, and most intakes that limit message size accept a compressed payload.

Two checks, in order. Well-formedness first: any XML editor, browser or command-line parser will tell you in a second whether the document parses, and a conversion that produced something unparseable is worth knowing about before anything else. That should always pass here.

Validation against the schema second, and expect it to fail the first time. The failures are informative — a missing namespace, an element in the wrong order, a required wrapper the JSON had no reason to include — and each one is a small fix in the JSON or in the output. Doing this once produces a template you can convert into for every subsequent payload.

The conversion is JavaScript in this tab: the browser parses the JSON, a small writer produces the XML, and no request carries the document anywhere. There is no sign-up, no queue and no daily allowance, and the free tier accepts up to 100 MB.

For this audience that is often the deciding factor rather than a nicety. The payloads that have to become XML are payments, claims, filings and patient or customer records — the exact categories where pasting a file into an unknown web service is a reportable event. Nothing here is sent, so there is nothing to report.