JSON to XML Converter — instant, pretty-printed

A JSON to XML converter saves you from writing one-off transformation scripts every time an API returns JSON but a downstream system — a legacy SOAP service, an enterprise integration bus, a config file format — still expects XML. Paste JSON into the box above and the tool parses it, walks the resulting object tree, and produces clean, pretty-printed XML with proper indentation, converting arrays into repeated sibling elements the way most XML consumers expect.

This free utility joins the small set of developer tools Arb Digital publishes for the same reason we build client integrations carefully — data has to move cleanly between systems, or everything downstream breaks.

What This JSON to XML Converter Does

The tool runs your input through `JSON.parse()` first, so you get immediate, specific feedback if the JSON itself is malformed — a missing comma, an unquoted key, a trailing comma — before any XML is even attempted. Once the JSON is confirmed valid, it recursively walks the resulting JavaScript object: object keys become XML element names, primitive values (strings, numbers, booleans) become element text content, nested objects become nested elements, and arrays become a sequence of repeated `` elements under their parent key, since XML has no native concept of an array the way JSON does.

The output is indented consistently — 2 spaces, 4 spaces, or tabs, your choice — so the result is immediately readable and diffable, not a single unbroken line of tags.

How to Use It

1. Paste valid JSON into the input box — an API response, a config object, test fixture data, anything.
2. Set a root element name if the target system expects a specific wrapping tag, since JSON's top level has no name but XML requires exactly one root element.
3. Choose your indent style to match the target codebase's conventions.
4. Read the live status panel — it tells you immediately if the JSON failed to parse, and where.
5. Copy the resulting XML into your file, request body, or test case.

How JSON Structures Map to XML

JSON and XML model data differently enough that the mapping needs a few explicit rules to be unambiguous. Both formats are described in their respective standards — JSON's grammar is defined in RFC 8259, and XML's syntax rules come from the W3C's XML 1.0 specification. A JSON object `{"name": "Arb Digital"}` maps directly to `Arb Digital` — each key becomes a tag pair wrapping its value. A JSON array, which has no direct XML equivalent, is represented as a series of same-named child elements: `{"products": [{"id":1},{"id":2}]}` becomes a `` element containing two `` children, one per array entry, since a bare array can't be a single well-formed element on its own.

Booleans and numbers are converted to their string representation as text content (`true`, `42`), since XML has no native typed values — everything in an XML document is ultimately text, and type information has to be recovered by whatever system parses it afterward, often via a schema like XSD.

Handling Invalid XML Element Names

Not every valid JSON key is a valid XML element name. XML tags cannot start with a digit or a punctuation character other than underscore, and they cannot contain spaces. A JSON key like `"2026-sales"` or `"first name"` would produce malformed XML if used as-is. This tool sanitizes problem keys automatically: leading digits get an underscore prefix, and spaces or other invalid characters are replaced with underscores, so the output XML is always well-formed even when the source JSON has messy key names.

It's worth knowing this happens, because a sanitized key name means the resulting XML tag won't always be an exact character-for-character match of the original JSON key — a detail that matters if the receiving system expects specific tag names and requires you to rename problem keys in the source JSON instead of relying on automatic sanitization.

When You Actually Need XML in a JSON World

JSON has been the dominant data-interchange format for web APIs for well over a decade, but plenty of real systems still speak XML natively and aren't going anywhere soon: many enterprise SOAP web services, several banking and healthcare (HL7-adjacent) integrations, RSS and Atom feeds, and a long tail of legacy enterprise resource planning systems all expect XML payloads. Rather than hand-rolling a converter for a one-time migration task or a small integration, a quick browser-based tool like this one gets you a correct result in seconds.

• Migrating a legacy integration that only accepts XML request bodies.
• Generating test fixtures for an XML-based API from JSON you already have.
• Producing a quick RSS/Atom-style feed snippet from structured JSON data.
• Converting configuration exported as JSON into an XML config format some tools still require.

Common Mistakes to Avoid

• Pasting JSON with trailing commas or single quotes — strict JSON requires double quotes and no trailing commas, unlike some looser JavaScript object syntax.
• Forgetting that JSON `null` has no clean XML equivalent — most converters render it as an empty element, which can be ambiguous downstream.
• Assuming array order is preserved automatically by every XML consumer — most do preserve document order, but always verify with your specific target system.
• Not setting a meaningful root element name, leaving a generic `` tag that tells a reader nothing about the payload's purpose.
• Sending sanitized key names to a system that expects the original JSON keys verbatim, without checking the sanitization rules first.

Related Free Tools From Arb Digital

Pair this with the String to Slug Converter for clean identifiers inside your data, the Cron Expression Generator for scheduling data-sync jobs, and the Open Graph Tag Generator for the pages you publish. Browse the full free online tools hub for more.

Why JSON and XML Never Map One-to-One

Converting between JSON and XML looks trivial until you hit the places where the two data models simply disagree. JSON has a small, fixed set of types — object, array, string, number, boolean, null — and keys are unordered. XML has no native concept of an array or a number; everything is an element or an attribute, order is significant, and text and child elements can mix inside the same node. Because of this mismatch there is no single "correct" conversion, only sensible conventions, which is why two converters can produce different-looking XML from the same JSON and both be valid.

The most visible consequence is how arrays are handled. XML has no array, so a JSON list has to become repeated elements — a ["a","b"] under the key tags typically becomes two <tags> elements, or a wrapper <tags> containing repeated <item> children. Neither is wrong, but if a downstream system expects one shape and gets the other, parsing breaks. Whenever you convert, decide on an array convention and keep it consistent across your whole pipeline rather than mixing styles document to document.

The Root Element, Attributes and Type Loss

XML has one iron rule JSON does not: a document must have exactly one root element. A JSON array or a JSON object with several top-level keys therefore cannot become valid XML without wrapping it in a single synthetic root — commonly <root> — which the tool above adds automatically. Forget this and you produce fragments that many strict XML parsers reject outright. It is the number-one reason a "valid JSON" input yields XML that fails validation somewhere else.

Then there is type loss. In JSON, 42 is a number and "42" is a string, and true is a boolean — distinctions the receiving code relies on. In plain XML, everything is text; <count>42</count> and <count>"42"</count> both arrive as strings unless a schema (XSD) re-imposes types. Round-tripping JSON → XML → JSON can therefore quietly turn numbers and booleans into strings if you are not careful. Knowing where these seams are — arrays, the single root, and lost types — lets you convert deliberately instead of being surprised when the "same" data behaves differently on the other side.

Choosing Between JSON and XML in the First Place

Because converting between the two is lossy at the edges, the better long-term move is often to choose deliberately rather than convert repeatedly. JSON won the web API era for good reasons: it is lighter, maps directly onto the objects and arrays of JavaScript and most modern languages, and is faster to parse, which is why REST and GraphQL APIs default to it. When you are moving data between a browser and a server, or between microservices, JSON is almost always the pragmatic choice and needs no conversion at all.

XML still earns its place where its heavier machinery is the point. It supports namespaces for mixing vocabularies, schemas (XSD) for strict validation and typing, attributes and mixed content for document-oriented data, and mature tooling like XPath and XSLT for querying and transforming. That is why you still meet it in enterprise messaging, government and financial data standards, publishing formats, and document markup. The honest rule: prefer JSON for lightweight data interchange, prefer XML when you need rich validation or are working inside an ecosystem built on it — and reach for a converter like the one above only when you are bridging two systems that made different choices.

Frequently Asked Questions