Understanding JSON ⇄ XML
Two shapes for the same data.
Convert cleanly, but know what each format won't carry across.
The fundamental shape difference.
JSON is a tree of values — strings, numbers, booleans, arrays, objects — keyed by names. XML is a tree of elements — each one a tag, optionally with attributes, containing text or other elements. JSON has no concept of attributes; XML has no concept of arrays. Round-tripping between them therefore needs a convention.
{ "user": { "name": "Ada" } } ⇄ <user><name>Ada</name></user>
Arrays in XML.
XML expresses repetition by repeating elements: <role>admin</role><role>editor</role>. JSON uses an explicit array. When converting JSON arrays to XML this tool emits one element per item; when converting XML to JSON it gathers same-named siblings into an array. A single<role> with no siblings becomes a string, not an array — keep that in mind for schemas that always expect a list.
Attributes vs. children.
XML elements can carry attributes — <book id="42"> — that have no JSON equivalent. The common convention (and the one this tool uses) is to fold attributes into the JSON object under prefixed keys: { "@id": "42", "#text": "…" }. Converting that JSON back to XML restores the attribute. If your XML uses attributes heavily and you need a strict round-trip, plan for those @-prefixed keys.
Comments, processing instructions, namespaces.
JSON has no syntax for any of these — comments, XML declarations (<?xml version="1.0"?>), and namespace prefixes vanish on the JSON side. If you need to keep a <?xml-stylesheet?> processing instruction or a set of xmlns declarations across the round-trip, treat XML as the source of truth and store JSON as a read-only projection.
When to pick which.
JSON wins for web APIs, JavaScript-heavy stacks, and anywhere minimal-overhead transmission matters — every byte you send on the wire counts. XML wins where you need attributes, schema validation (XSD), namespaces (industry-specific dialects like SOAP, OOXML, SVG), or document-style content mixing markup and text. RSS and Atom feeds, configuration files for older tooling, and EDI document formats stay XML because the alternatives are worse, not because XML is enjoyable.