JSON and XML Converter
Convert both ways between JSON and XML: arrays become repeated tags, attributes come back as @_ keys, and the mapping rules are fixed in both directions.
Legacy services, SOAP envelopes and a number of industry schemas still speak XML, and the hard part of moving that data into JSON is not syntax but structure. XML expresses a list by repeating a tag, JSON expresses it with an array, and a one-element list looks exactly like a single value. Attributes have no place in a JSON object either. The rules here are fixed so the result is predictable: attributes get a documented prefix, arrays become repeated tags.
The conversion uses fast-xml-parser and runs entirely in the browser, so payloads from internal systems are safe to paste. It maps elements, attributes and text and nothing else: there is no DTD or XSD validation, and comments, CDATA markers and namespace declarations are not carried over. Keep a copy of the original file if those details matter.
How arrays are represented
XML has no array type, so a list can only be written as repeated sibling tags. Going from JSON to XML, the root object is wrapped in a root element and an array property becomes several tags with the same name; if the root itself is an array, the items are written as repeated item tags inside root. That leads to the structural trade-off this mapping cannot escape: a one-element array and a single object produce identical XML, so parsing back cannot tell them apart. The parser therefore merges repeated same-name tags into an array and leaves a tag that appears once as a scalar, which means a one-element array is silently downgraded.
Attributes and text
Parsing XML into JSON turns attributes into keys with an @_ prefix, so id="1001" becomes "@_id": "1001", and the values stay strings so a version number like 1.0 or a code like 007 is not rewritten. Element text is inferred rather than left alone: 007 becomes the number 7, 1e5 becomes 100000, and true becomes a boolean, so an identifier that merely looks numeric should be quoted in the XML or corrected afterwards. An element with no children and no text becomes an empty string rather than null, and a tag that appears once stays a scalar. In the other direction, JSON keys beginning with @_ are emitted as attributes and a #text key becomes the element text, which is how attributes can be round-tripped.
Where this mapping fits
This is a good fit for configuration files, simple API payloads and log fragments, and a poor fit for anything that depends on what XML adds on top of a tree: DTD or XSD validation, comments, CDATA sections, processing instructions and namespaces. Namespace prefixes are treated as part of the tag name — soap:Envelope stays a key called soap:Envelope and xmlns declarations come back as attributes — so the hierarchy survives but the namespace meaning is gone. Malformed XML raises an error instead of being repaired, and input with no tags at all is rejected up front. If you need a round trip that keeps its meaning, prefer the YAML converter, which uses the same tree model in both directions.
Frequently asked questions
- Why can I not tell that an array became an array?
- Because XML has no marker for a list: repetition is the only signal, and one repeated tag is indistinguishable from one value. Parsing back therefore converts repeated tags into arrays and single tags into scalars, so a one-element array loses its array-ness. If the shape has to survive, wrap lists in a container element in your own schema so the wrapper is always present.
- Why do attributes have a prefix, and why are their values always strings?
- The @_ prefix keeps an attribute and a child element of the same name from colliding in one JSON object, and it matches the builder convention that turns @_-prefixed keys back into attributes. Attribute values are kept as strings on purpose: version numbers like 1.0 and codes like 007 are identifiers, and type inference would silently rewrite them.
- Are comments and CDATA preserved?
- No. Only elements, attributes and text are mapped. Comments are dropped, CDATA delimiters are removed and the enclosed text is inlined, and document and namespace declarations are not carried over; there is no DTD or XSD validation either. A file that depends on those parts should not be round-tripped through JSON.
- Can I control the generated root tag name?
- No — the root element is always root and array items are always item. Put a named key at the top level of your JSON if you want a specific child tag, or edit the generated XML directly. The page does not expose options for tag names.