XML to JSON Converter

Converting XML to JSON means reading a markup document and rebuilding the same information as JSON data: elements become keys, their text becomes values, and nesting becomes nesting.

It is the harder direction of the two. Going from JSON to XML, every JSON construct has somewhere to go. Coming back, XML carries three things JSON has no slot for — attributes, mixed content, and the difference between one child and a list of one — so a converter has to invent conventions. Every XML-to-JSON tool invents slightly different ones, which is why the same document converted by two tools rarely matches.

1<user id="1042">2  <name>Ada Lovelace</name>3  <city>London</city>4</user>

1{2  "user": {3    "@id": "1042",4    "name": "Ada Lovelace",5    "city": "London"6  }7}

Two decisions are already visible. The id attribute became @id, marking it as having come from an attribute rather than a child element — because otherwise it would be indistinguishable from <id>1042</id>. And "1042" is a string, not a number, because XML never said it was one.

Because JSON is what the receiving code wants to work with. XML is what a great deal of existing, working software still emits, and the gap between the two is where conversion lives.

• It is native to JavaScript. JSON parses into ordinary objects with no library and no traversal API. Working with XML in a browser means DOM methods, node lists and namespace-aware lookups.
• It is smaller. XML writes every name twice. Dropping the closing tags typically takes a third off, which matters on every request.
• It is easier to store. Document databases, message queues and log pipelines mostly speak JSON. Converting on arrival means one format inside your system rather than two.
• It contains the boundary. Converting once, at the edge, keeps XML out of the rest of the codebase — which is what makes eventually replacing the XML source a small change rather than a rewrite.
• It is easier to read. For inspecting an unfamiliar payload, a JSON tree beats angle brackets, which is why this tool has one built in.

1. 1. The XML is parsed. The document is read into a tree of elements, attributes and text. If it is not well-formed, conversion stops here and the problem is reported with its line and column — a half-parsed document would produce JSON that quietly omitted whatever came after the mistake. The XML formatter is the easier place to track down a well-formedness error in a long document.
2. 2. Entities are resolved. & becomes &, © becomes ©, and CDATA sections are taken literally. This happens during parsing, so the values that reach the conversion are already the real text.
3. 3. Each element is converted, children first. An element with only text becomes that text. An element with attributes or children becomes an object holding both.
4. 4. Repeated names collapse into arrays. The first <item> is stored directly; the second turns it into an array and appends. This is why the output shape depends on how many items the document happened to contain.
5. 5. Whitespace is discarded where it means nothing. Indentation between tags is formatting, not content, so it is dropped. Text inside CDATA never is.

That last step is worth dwelling on. In pretty-printed XML, every pair of tags has a newline and some spaces between them. Treating those as text would give almost every element a #text of "\n " and make the output unusable — so ordinary text is trimmed and dropped when empty, while anything inside a CDATA section is kept exactly as written.

XML is a document format that grew out of publishing; JSON is a data format that grew out of a programming language. Nearly every difference follows from that.

• Types. JSON has numbers, booleans, strings and null. XML has text. This is the single biggest thing gained in one direction and lost in the other, and the reason every value here comes out as a string.
• Arrays. JSON has them. XML expresses repetition by convention, which is why converting has to guess from the number of siblings present.
• Attributes. XML has two places to put a value; JSON has one. Bridging that needs a naming convention, and no convention is standard.
• Comments. XML has them; JSON does not. They are dropped, and counted so you can see they existed.
• Mixed content. Text with markup inside it is natural in XML and has no JSON equivalent. Documents tend to stay XML for exactly this reason.
• Size and speed. JSON is smaller and faster to parse. XML is more expressive about documents. Neither fact makes one correct.

The conversion is therefore not quite lossless. Comments, the declaration, processing instructions, the element-versus-attribute distinction and whitespace between tags do not survive in full. Everything that carries data does.

This is the decision that most distinguishes one converter from another, because JSON has no concept of an attribute. Consider:

1<user id="1042">2  <id>internal-7</id>3</user>

Both the attribute and the child are called id, and they mean different things. Writing both as plain keys would collide. The two common answers are:

Prefixing

Attributes get a marker character, conventionally @. The document above becomes:

1{2  "user": {3    "@id": "1042",4    "id": "internal-7"5  }6}

Flat, readable, and each attribute stays next to the elements it sits with. The cost is that @is awkward in some languages’ property access, and a JSON key genuinely starting with @ would be ambiguous.

Grouping

Attributes are collected into a nested object instead:

1{2  "user": {3    "_attributes": { "id": "1042" },4    "id": "internal-7"5  }6}

Unambiguous, and easy to iterate over as a set. The cost is an extra level of nesting on every element that has attributes, and paths that get longer.

Both are offered here, with the prefix and the group key editable, because the right answer depends entirely on what reads the JSON afterwards. If you are feeding a schema or a library that already expects one convention, match it — the conversion is easy to redo, and reshaping the output downstream is not.

Whichever you pick, the JSON viewer is a quick way to check the shape that came out, and the JSON to XML converter goes back the other way when something downstream wants XML again.