JSON to XML Converter
What is JSON to XML Conversion?
JSON to XML converts structured JSON data into XML markup so information can move between systems that expect different exchange formats. JSON uses objects, arrays, numbers, strings, booleans, and null, while XML uses elements, attributes, text nodes, and namespaces. Because of that, conversion is not always one-to-one: array names, attribute mapping, empty values, special characters, and ordering need sensible representation. The tool supports SOAP-adjacent integrations, legacy enterprise systems, data migration, test payloads, and documentation. For production interfaces, the result should be validated against the expected XSD, API contract, or partner format, because well-formed XML is not automatically acceptable business data.
How to Use
How to use
- Paste or enter JSON data in the left input box
- Optionally customize the root element name
- Select indent size (2 spaces, 4 spaces, or Tab)
- Converted XML displays on the right with syntax highlighting
- Click Copy or Download to save the result
Conversion Checks
- Review arrays, null values, and attribute-like fields after conversion; JSON and XML do not model data in exactly the same way.
- Choose a stable root element name before copying the XML into an API request, config file, or test fixture.
Use Cases
Technical Principle
JSON (RFC 8259, derived from JavaScript object literals) and XML (W3C XML 1.0, originally 1998) are both tree-structured serialisation formats, but their grammars differ. JSON has objects (key/value maps with string keys), arrays (ordered lists), and six scalar types (string, number, boolean, null, and the structural types). XML has elements (start/end tag pairs enclosing text or child elements), attributes (name/value pairs on the start tag), text nodes, comments, processing instructions, and CDATA sections. The conversion is a structural transform with no canonical answer — every existing convention (BadgerFish, JSONML, SOAP/RPC encoding, OOXML's flat schema, XBRL's linkbase format) is a different rule for the same input. The 'attribute vs child element' decision is the central ambiguity. JSON's only metadata lives in the key name, so a JSON object like `{"id": "42", "name": "Alice", "admin": true}` does not say which keys are 'metadata' and which are 'data'. Three common conventions: (1) the page's default — scalars become text content, while the original JSON key of a nested attribute bag (recognised by being a non-array object whose only values are scalars) becomes an XML attribute prefixed with `@` (BadgerFish convention). (2) JSONML — every JSON object becomes an element with the key 'tag' as the element name, the key 'attr' as the attribute map, and child entries as children. (3) oData / Atom — JSON objects become elements and arrays are inlined with an array-name wrapper element. Each rule is provably correct for some downstream consumer and provably wrong for another, which is why no converter-to-XML has ever been universally accepted. Arrays are the second ambiguity. JSON arrays are ordered lists; XML has no native array type. The three standard solutions: (a) repeat child elements (the page's default, the OOXML/SOAP convention): `[1, 2, 3]` → `<root><item>1</item><item>2</item><item>3</item></root>`. (b) Wrap in a container: `<root><items><item>1</item>...</items></root>`. (c) Encode the array as a single delimited string and document the delimiter (CSV-in-XML, only when the consumer parses it). Each is correct for a different downstream XSD; the conversion step needs to know which one to emit. XML element names must be valid QName tokens (XML 1.0 §2.3 / XML Namespaces 1.0 §3): start with a letter, underscore, or colon, then letters, digits, hyphens, underscores, periods, or colons. JSON allows keys like '123' or 'first name' that violate this — the converter must either rename them (slugify to first_name, prefix with _) or fail. JSON string content also needs entity escaping in element text and attribute values: `&` → `&`, `<` → `<`, `>` → `>` (only required in text in older XML, but always safe), `"` → `"` and `'` → `'` in attributes, and any character outside the encoding's range as `&#xHHHH;`. The five built-in entities plus numeric character references are mandatory in XML; HTML's additional named entities (` `, `©`) are not defined in plain XML and need an explicit DOCTYPE if used. The output document also needs a prolog and namespace declarations: `<?xml version="1.0" encoding="UTF-8"?>` first, then any xmlns declarations. If the target system uses namespaces (SOAP uses `http://www.w3.org/2003/05/soap-envelope`, XSLT uses `http://www.w3.org/1999/XSL/Transform`), the prefix mappings are added as `xmlns:prefix="uri"` attributes on a root element. JSON has no namespace concept, so the choice of which URI to use is project-specific. For empty values, JSON null is usually expressed as `<key xsi:nil="true"/>` (the XML Schema convention) or `<key></key>` (the empty element convention). The converter picks one; the right answer depends on the consumer's XSD validation. For the inverse direction (XML → JSON), the same ambiguities in reverse: attributes map to a `@attributes` key in BadgerFish, CDATA maps to a `$` or `#text` key, mixed-content elements (text + child elements interleaved) have no clean JSON representation and are usually emitted as a string concatenation. Real-world converters always expose 'attribute key', 'text key', 'array wrapper' options — there is no way around it.
- JSON (RFC 8259) and XML (W3C XML 1.0, 1998) are both tree-structured serialisation formats; the conversion is a structural transform with no canonical answer, so multiple conventions (BadgerFish, JSONML, SOAP, OOXML) coexist for the same input.
- Attribute vs child element: scalars default to text content; nested attribute-bag objects (only-scalar values) become @-prefixed attributes (BadgerFish). JSONML uses 'tag' / 'attr' keys. oData / Atom uses wrapper elements.
- Arrays: the page's default repeats child elements (OOXML/SOAP convention). Alternatives: wrap in a container element, or encode as a delimited string. JSON's array ordering is preserved in the XML output.
- XML element name rules: must start with a letter, underscore, or colon, then letters/digits/hyphens/underscores/periods/colons (XML 1.0 §2.3). JSON keys like '123' or 'first name' are invalid XML names and must be slugified or rejected.
- Entity escaping: `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`, any other encoding character as `&#xHHHH;`. The 5 built-in entities are mandatory; HTML extras like ` ` need an explicit DOCTYPE.
- Document prolog: `<?xml version="1.0" encoding="UTF-8"?>` is the standard first line. xmlns declarations on the root element declare namespace prefixes; JSON has no namespace concept, so the converter picks per project.
- JSON null → XML: either `<key xsi:nil="true"/>` (XML Schema convention) or `<key></key>` (empty element). The choice must match the consumer's XSD, otherwise validation fails.
- Inverse direction XML → JSON has the same ambiguities: CDATA sections become `$` or `#text` keys (BadgerFish), mixed-content elements (text + child elements interleaved) have no clean JSON form and are usually concatenated into a string.
Examples
Object -> Element
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>Array -> Elements
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>Nested Structure
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>FAQ
How does the converter map JSON to XML?
Each JSON object becomes an XML element. Object keys become child element names; primitive values become element text. Arrays repeat the parent element multiple times. Special characters in text are escaped (& → &, < → <).
Why is JSON-to-XML not always lossless?
JSON has explicit number/boolean/null types; XML has only text. JSON allows keys with spaces or special characters; XML element names cannot. Arrays at the top level have no obvious XML equivalent. The page uses heuristics (wrapper element 'root', invalid keys sanitised) to bridge these gaps.
How are array values represented in XML?
Each array element becomes a sibling element with the same name. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. The wrapping is configurable; some pages let you pick the singular element name explicitly.
What about JSON keys that aren't valid XML names?
XML element names cannot start with a digit, contain spaces, or include certain symbols. The page sanitises by replacing invalid characters with underscores or wrapping in CDATA. The result is valid XML but the round-trip is not exact.
Are JSON null and boolean preserved?
null becomes an empty element or omits the element depending on settings. true/false become the literal text 'true' or 'false'. There is no XML standard for these types - downstream parsers must apply their own type interpretation.
Can I add XML attributes?
JSON has no attribute concept, so the generator emits everything as elements by default. Some converters use a special key prefix (e.g. '@id') to indicate attributes - check the page options if attribute output matters for your XML schema.
Is the conversion local?
Yes. JSON parsing and XML generation happen in your browser. Inputs are not uploaded.