About JSON to XML
XML and JSON have genuinely different data models, so this conversion involves choices rather than a mechanical mapping - which is why two converters can produce different, equally defensible output for the same input.
The core mismatch is that JSON distinguishes objects, arrays, strings, numbers, booleans and null, while XML has elements, attributes and text. XML has no array type: a JSON array becomes repeated sibling elements, which means a single-element array and a bare value convert identically and cannot be told apart on the way back. Nor does XML have types - every value becomes text, so 42, "42" and true all arrive as strings unless a schema says otherwise.
Two things reliably break a naive conversion. XML element names cannot start with a digit or contain spaces, so a JSON key like "2024" or "first name" is not a legal element name and must be escaped or moved into an attribute. And JSON null has no XML equivalent - it becomes an empty element, which is indistinguishable from an empty string. Round-tripping JSON through XML is therefore lossy in several directions at once.
This runs in your browser, so a real payload is never uploaded - which matters when the document you are converting is a production API response rather than a toy example.
How to use the JSON to XML
- Paste the JSON. If it does not parse, fix that first - the error will name the position.
- Convert, and read the XML output.
- Check the specific cases listed below before relying on the result - XML and JSON do not model data identically.
- Copy the output, or convert back to confirm the round trip does what you expect.
Examples
-
JSON input
{"user":{"id":1,"name":"Ada"}}
When you need this
- Turning an API response into XML for a config file, a spreadsheet, or a type definition.
- Producing a XML fixture from real data rather than writing it by hand.
- Checking how a nested structure maps into XML before committing to it.
- Converting a sample from documentation into the form your tooling needs.
Common problems and what causes them
- Keys that are not legal XML element names
- XML names cannot begin with a digit or contain spaces or most punctuation, so JSON keys like "2024", "first name" or "user-id" (legal) versus "user id" (not) need escaping or relocation into attributes. A converter that ignores this produces XML that will not parse.
- Arrays becoming ambiguous
- XML has no array type, so [1] and 1 both become a single element and cannot be distinguished when converting back. Wrap arrays in a container element if the round trip matters.
- Type information lost
- Every XML text node is a string, so 42, "42", true and "true" all become the same thing. Only an XML Schema can restore the distinction, and most converters do not emit one.
- null with no representation
- JSON null usually becomes an empty element, which is identical to an empty string. Some converters use xsi:nil="true"; check which convention the consumer expects.
- Characters that must be escaped
- &, <, > and, inside attributes, quotes must be escaped as entities. Control characters below U+0020 other than tab, newline and carriage return are not permitted in XML 1.0 at all, even escaped - a JSON string containing one cannot be represented.
- No single root in the source
- XML requires exactly one root element. A JSON document that is a top-level array needs a synthetic wrapper element, and different converters name it differently.
FAQ
- Is JSON to XML conversion lossless?
- No, in several directions. XML has no array type, no numeric or boolean types, and no null, so array cardinality, value types and null-versus-empty-string are all lost. Round-tripping will not reproduce the original document.
- How are JSON arrays represented in XML?
- As repeated sibling elements with the same name. Because XML has no array concept, a one-element array and a plain value produce identical XML, which is why a container element is worth adding if you need to convert back.
- What happens to a JSON key that is not a valid XML name?
- Element names cannot start with a digit or contain spaces, so "2024" and "first name" must be escaped, renamed, or moved into an attribute. Converters differ in which they choose.
- Should I use attributes or child elements?
- There is no single right answer, which is much of why XML-to-JSON mappings vary. The common convention is attributes for metadata and scalar properties, child elements for structure. Pick one and apply it consistently.
- Is my data uploaded when I convert it here?
- No. The conversion runs entirely in your browser with no network request, so pasting a real payload does not transmit it. The page works offline once loaded.
- Are attributes supported?
- Output uses element nesting; attribute-style XML is not generated.
Related reading
- JSON formatter fix the input first
- JSON validator