Can I output attributes instead of child elements?

Yes, by naming the key with the @_ prefix: {"book":{"@_id":"1"}} produces . That is the same convention the XML to JSON converter uses, so the two round-trip.

Why was my key renamed?

Because it would have produced invalid XML. Element names cannot start with a digit or contain spaces, and the prefix "xml" is reserved. The warning lists every rename.

Can I validate the result against an XSD?

Not here. This guarantees well-formed XML, correct syntax, but not conformance to a particular schema. Element ordering and required fields are schema concerns that need a dedicated validator.

Converters

JSON to XML

Turn JSON into well-formed XML with a configurable root element.

Reverse

LiveCtrl+↵

Inputjson0 lines · 0 chars

Outputxml0 lines · 0 chars

Options

Root element name

Indent width

Spaces per level of nesting.

About this tool

Converting JSON to XML requires supplying structure that JSON does not have: XML needs exactly one root element, and every value needs an element name. This converter makes both explicit and guarantees the result is well-formed, rewriting any key that would produce illegal markup.

The common reason to do this is feeding a legacy system, SOAP services, enterprise integrations and older configuration formats often accept only XML.

How to use it

Paste or upload JSONAny valid JSON works, including a bare array.
Name the root elementXML requires a single root. The default is <root>; change it to match the schema you are targeting.
ConvertPress Convert to XML, or use Ctrl+Enter.
Copy or downloadSave as .xml or copy the markup.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Object with a nested array

Input

{"id":42,"tags":["a","b"]}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <id>42</id>
  <tags>
    <item>a</item>
    <item>b</item>
  </tags>
</root>

Array entries each need an element name; <item> is the default.

Keys that are not valid XML names

Input

{"2024":1,"first name":"Ada"}

Output

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <_2024>1</_2024>
  <first_name>Ada</first_name>
</root>

An element name cannot begin with a digit or contain a space, so both keys are rewritten.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Every document gets a single root: XML permits exactly one top-level element. An object with several top-level keys, or an array of any length, therefore has to be wrapped, by default in <root>. A top-level array additionally needs a name for each entry, since XML has no anonymous list; each element becomes <item> unless you rename it.
Keys that are not legal element names get rewritten: XML names must start with a letter or underscore and cannot contain spaces or most punctuation. A key like "2024" becomes <_2024>, "first name" becomes <first_name>, and anything beginning with "xml" is prefixed because that string is reserved by the specification. A warning lists what changed, the rewrite is not reversible, so converting back will not restore the original key.
Special characters are escaped: The characters &, <, > and quotes in attribute values are replaced with their entity references, so a value containing markup cannot break the document structure. This means output is always well-formed regardless of what your strings contain.
null becomes an empty element: XML has no null, so null is written as an empty element: <score/>. That is indistinguishable from an empty string, so the distinction is lost. Schemas that need explicit nullability normally use the xsi:nil="true" attribute, which this converter does not add automatically.
Types are not preserved: XML content is text. The number 42, the string "42" and the boolean true all serialise identically, so type information exists only in a schema. Converting back applies inference and may not reproduce the original JSON types exactly.

Limitations

Keys that are not valid XML names are rewritten, which is not reversible.
null and empty string both become an empty element.
Output is well-formed but not validated against any schema.
Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Can I output attributes instead of child elements?: Yes, by naming the key with the @_ prefix: {"book":{"@_id":"1"}} produces <book id="1">. That is the same convention the XML to JSON converter uses, so the two round-trip.
Why was my key renamed?: Because it would have produced invalid XML. Element names cannot start with a digit or contain spaces, and the prefix "xml" is reserved. The warning lists every rename.
Can I validate the result against an XSD?: Not here. This guarantees well-formed XML, correct syntax, but not conformance to a particular schema. Element ordering and required fields are schema concerns that need a dedicated validator.