How do I control whether a value becomes an attribute or an element?

Prefix a key with @ to make it an attribute of its parent element. For example, { "book": { "@id": "b1", "title": "..." } } produces ... . Keys without the prefix become child elements.

How are JSON arrays represented in XML?

XML has no array type, so each item is written as a repeated element with the same tag name as the key. An array of three items under "item" produces three elements as siblings.

Can an element have both attributes and text?

Yes. Combine @-prefixed keys for the attributes with a #text key for the inner text. { "price": { "@currency": "USD", "#text": "9.99" } } becomes 9.99 .

Are special characters escaped?

Always. Ampersands become &, angle brackets become < and >, and quotes are escaped inside attribute values. This guarantees the result is well-formed XML that any parser will accept.

Does my JSON get uploaded?

No. The conversion is fully client-side, so your JSON never touches a server. You can safely convert payloads containing credentials or internal identifiers.

JSON to XML Converter

Stable

Convert JSON into well-formed XML with attribute and element control.

Everything is processed locally in your browser

About JSON to XML Converter

Convert JSON into well-formed, properly indented XML entirely in your browser. This JSON to XML converter maps object keys to elements, expands arrays into repeated tags, and can emit attributes from keys you prefix with @. Special characters are escaped automatically so the output is valid XML you can hand to a legacy SOAP endpoint, an RSS feed, or an XML-only integration.

Features

Maps object keys to elements and arrays to repeated sibling tags
Emits XML attributes from keys prefixed with @ (e.g. "@id")
Writes text content of mixed nodes from a #text key
Escapes &, <, >, " and ' so the output is always well-formed
Adds an optional XML declaration and configurable indentation
Wraps the document in a root element you can name yourself

How to use JSON to XML Converter

1
Paste your JSON
Provide a JSON object. Use @-prefixed keys for attributes and a #text key when a node needs both attributes and text content.
2
Convert to XML
The converter walks your JSON, building elements and attributes and escaping special characters as it serializes.
3
Copy the XML
Copy the indented XML or download it as an .xml file, ready for a SOAP request, feed, or config.

Examples

JSON with an attribute to XML

The @id key becomes an attribute; other keys become child elements.

Input

{
  "book": {
    "@id": "b1",
    "title": "The Pragmatic Programmer",
    "author": "Hunt & Thomas"
  }
}

Output

<?xml version="1.0" encoding="UTF-8"?>
<book id="b1">
  <title>The Pragmatic Programmer</title>
  <author>Hunt &amp; Thomas</author>
</book>

How JSON to XML conversion works

Two data models that do not line up

XML and JSON look similar in that both nest, but their models differ in ways that force decisions on any converter. XML distinguishes attributes from child elements, has no arrays, has no native number or boolean type, allows mixed content where text and elements sit side by side, and supports namespaces. JSON has arrays and typed scalars, one kind of member, and no namespaces.

Because of that mismatch there is no canonical mapping. Several conventions exist - JsonML, Parker, BadgerFish, and the Spark and GData variants - and each trades fidelity against readability. Parker produces clean JSON but discards attributes. BadgerFish keeps everything by prefixing attribute keys with `@`, at the cost of a noisier document. No convention is both lossless and tidy, because the models genuinely do not correspond.

The most immediate consequence is arrays. JSON has them; XML does not. A single `<item>` and a list of `<item>` elements look structurally identical to an XML parser, so the converter cannot tell a one-element collection from a scalar. This is the single most common source of bugs in XML/JSON interchange.

Root elements and element naming rules

Every XML document needs exactly one root element. JSON has no such requirement - a document can be an array, or a bare string, or a number. So converting `[1,2,3]` requires inventing a wrapper element to hold the values, because there is nowhere else for them to live.

XML element names are also more restricted than JSON keys. A name must start with a letter or underscore, cannot contain spaces, and cannot begin with the string `xml` in any casing. A JSON key like `"2024 revenue"` is perfectly legal and cannot be an element name at all.

Converters resolve this by sanitising - prefixing a leading digit, replacing spaces with underscores. That produces valid XML but breaks the round trip, because the original key cannot be recovered from the sanitised name. If a faithful round trip matters, rename the keys in the JSON before converting.

What has to be escaped, and what CDATA does not solve

XML reserves five characters. `<` and `&` must always be escaped, as `<` and `&`. `>`, `"` and `'` must be escaped in particular contexts and are conventionally escaped everywhere for safety. Any JSON string value containing HTML, or an ampersand in a company name, needs this treatment.

CDATA sections are often reached for as an alternative, and they help with readability rather than correctness: content inside `<![CDATA[...]]>` is not parsed, so markup can sit there literally. The catch is that CDATA cannot contain the sequence `]]>`, so it is not a general escape hatch - content has to be split across two sections when that sequence appears.

Control characters are a harder limit. XML 1.0 forbids most of them outright, even escaped, so a JSON string containing a raw control character cannot be represented in XML 1.0 at all. If that is a real possibility in your data, base64-encode the field before converting.

Reference

How JSON constructs map to XML

JSON	XML	Fidelity
Object	Element with children	Direct
Array	Repeated sibling elements	Lossy - single vs. list is ambiguous
String	Element text content	Direct, once escaped
Number	Text content	Type is lost; XML has no number type
Boolean	Text 'true' / 'false'	Type is lost
null	Empty element or xsi:nil	Convention-dependent
Root array	Requires an invented wrapper	Structure added
Key "2024 revenue"	Sanitised name	Original key not recoverable

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need to send data to a SOAP or legacy enterprise system: This is the main reason the conversion exists. Match the target schema rather than accepting the default mapping.
You are choosing a format for a new interface: Use JSON. XML is worth the extra weight only when you specifically need namespaces, schema validation via XSD, or XSLT transformation.
You are converting the other direction: The XML to JSON tool handles that, including attributes and namespaces.
You need to match a specific XSD: A generic converter will not produce schema-conformant output. Generate from the XSD with proper tooling instead.

Use cases

Send JSON data to a legacy SOAP or XML-RPC web service
Generate an RSS or Atom feed from JSON records
Produce XML config or manifest files from a JSON source of truth
Bridge a modern JSON API with an XML-only enterprise system
Create XML fixtures for testing an XML parser

Troubleshooting common errors

A single-element array became a scalar on the round trip

Why: XML cannot distinguish one `<item>` from a list of one `<item>`.

Fix: This is the fundamental ambiguity of XML/JSON mapping. Add a wrapper element for collections, or tell your XML parser which elements are always arrays.

Element names have underscores or prefixes that were not in the JSON

Why: The keys were not valid XML names - they contained spaces, or started with a digit.

Fix: Rename the keys in the JSON before converting. Sanitised names cannot be reversed.

The XML is rejected as not well-formed

Why: Unescaped `&` or `<` in a string value, or a control character that XML 1.0 forbids.

Fix: Escape the reserved characters. For control characters, base64-encode the field, since XML 1.0 cannot carry them even escaped.

Numbers arrive as strings at the far end

Why: XML has no numeric type; everything is text unless an XSD declares otherwise.

Fix: Expected. The consumer has to coerce, ideally guided by a schema.

Converting a top-level array needs a root name

Why: XML requires exactly one root element, and an array has no name.

Fix: Wrap the array in a named object in the JSON first, so the wrapper name is your choice rather than a default.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Arrays cannot be represented unambiguously, so single-element collections are lossy on the round trip.
JSON keys that are not valid XML names are sanitised and cannot be recovered.
Type information is lost - XML content is text unless an XSD says otherwise.
Control characters cannot be represented in XML 1.0 at all.
Output follows a general convention and will not conform to a specific XSD.

Frequently asked questions

XML to JSON Converter

Parse XML into predictable JSON with clear attribute and text mapping.

JSON to YAML Converter

Turn JSON into clean, readable YAML for configs, pipelines and manifests.

JSON to CSV Converter

Flatten an array of JSON objects into spreadsheet-ready CSV.

Online JSON Formatter & Validator

Pretty-print JSON with configurable indentation and instant validation.

Learn more

How to Convert JSON to XML Without Losing Attributes or StructureXML has no native concept of arrays or attributes the way JSON does. This guide explains the mapping rules and shows how to convert JSON to clean, valid XML without uploading anything.