Convert JSON to XML

JSON and XML both describe hierarchical data, but their type systems are not the same. JSON has a small set of native types — strings, numbers, booleans, null, objects, and arrays — and a parser hands them back with those types intact. XML has exactly one primitive: text. Everything in an XML document is an element, an attribute, or a text node, and a bare parser sees "184.5" and "true" as strings until a schema or your own code says otherwise.

That gap drives every decision this converter makes. A JSON key maps cleanly to an element name, and a nested object maps to a nested element, because both are just named containers. Scalar values, however, have to collapse into text content: the number 184.5 and the boolean true are emitted exactly as they read, with no quotes and no type marker. If a downstream system needs to know that a field is numeric or boolean, it must apply an XML Schema or cast the values itself after parsing.

XML also carries features that have no JSON counterpart — attributes, namespaces, processing instructions, comments, and mixed content where text and elements interleave. A one-way JSON-to-XML mapping cannot invent meaning for those, so it produces a deliberately plain, element-only document that stays predictable and easy to reason about.

JSON arrays have no direct equivalent in XML, so a convention is required. The widely used idiom is repeated sibling elements: a list becomes several elements that share one tag name. This converter follows that pattern by repeating the array parent’s key. An "items" array of two objects produces two <items> elements, and a "tags" array of two strings produces two <tags> elements. When the entire top-level value is an array, each item is wrapped in a generic <item> element so the document still has a single root.

The alternative — a wrapper element such as <items> that holds numbered children — is also valid, but repeated siblings keep the tag name tied to the data and read naturally in feed-shaped documents. The trade-off is that the array boundary is implicit: a consumer infers "list" from the repetition rather than from an explicit container.

The converter also never emits attributes; every value is an element. JSON gives no signal about which fields should be attributes versus child elements, and that choice is a genuine XML modeling decision with no canonical answer. An element-only document sidesteps the ambiguity, stays lossless, and round-trips predictably. It is more verbose than an attribute-heavy design, but it is far easier to generate, diff, and consume programmatically.

Text content is escaped so the output is always well-formed. The three characters that are significant in element text — &, <, and > — are replaced with &amp;, &lt;, and &gt;. A title like "Tom & Jerry" becomes "Tom &amp; Jerry". Quotes and apostrophes are left as-is, which is correct here: those only need escaping inside attribute values, and this converter never produces attributes.

Element names come straight from your JSON keys, but XML names are stricter than JSON keys. An XML name must begin with a letter or underscore and may then contain letters, digits, hyphens, periods, and underscores. The converter sanitizes each key to fit: any other character is replaced with an underscore, and a name that starts with a digit is prefixed with one. So "order-id" is kept, "user name" becomes "user_name", "@type" becomes "_type", and "2ndItem" becomes "_2ndItem". An empty key falls back to a single underscore.

A few structural rules round out the mapping. Empty objects, empty arrays, and null values render as self-closing tags such as <tag/> rather than empty pairs. The document opens with an <?xml version="1.0" encoding="UTF-8"?> declaration, wraps its contents in exactly one <root> element, and uses two-space indentation throughout, so the result is parseable by any standard XML tool.

The most common reason to convert is interoperability with systems that speak XML. SOAP web services, older enterprise middleware, and many government or banking integrations expect XML request and response bodies. When a modern API hands you JSON and a legacy consumer needs XML, this converter gives you a clean, escaped payload to adapt into the target envelope. It is equally handy for populating XML configuration files or build descriptors from data you already model in JSON.

Feed- and document-shaped data maps especially well, because the repeated-element pattern mirrors formats like RSS, Atom, and sitemaps, where a channel or feed contains many same-named entries. A JSON array of records translates directly into the repeated <item>-style elements those formats expect, giving you a starting point you can drop into a template.

Once the JSON side is in good shape, open it in the full editor to go further. There you can format and validate it, explore deep structures as an interactive tree or a mind map, and ask the AI copilot to explain the schema or reshape the data before you convert. The converted XML is copy-ready on this page; the editor is where you refine the JSON that feeds it.