How to Convert XML to JSON
Paste well-formed XML and switch to XML-to-JSON. Review the generated object, especially attributes and repeated elements. The browser parses the document locally, and malformed markup needs correcting before a useful result can be generated.
How XML Attributes Map to JSON
XML attributes must become properties using the converter’s attribute naming convention. This distinguishes them from child elements with the same name. Inspect the output and keep that convention consistent in downstream code.
Repeated Elements and Arrays
Repeated sibling elements with the same name can become arrays. A single occurrence may produce a scalar or object instead, so normalize the shape if an API expects an array regardless of count.
Namespaces, Text Nodes and Edge Cases
Namespaces and mixed text require particular care because JSON has no direct mixed-content model. Review documents with text interleaved among children. Do not assume document order, comments and whitespace round-trip through a generic object mapping.
XML to JSON Examples
For repeated item elements, inspect whether item becomes an array of values or objects. Then compare counts and attributes against the XML source. Use a schema or application test to verify the generated structure.
More examples and technical details
Why This Conversion Needs a Convention
XML to JSON is not a symmetric operation, and understanding why saves a lot of confusion. XML has four distinct kinds of node content: attributes, text, child elements, and comments. JSON has exactly two things: keys and values. Four into two does not go, so every converter invents a convention to encode the extra distinctions.
The most widely used convention prefixes attribute names with an @ sign and stores an element's own text under a key such as #text. Both characters are chosen precisely because they cannot appear at the start of an XML element name, so there is no risk of a collision with a real child.
Side by Side Example
An RSS style feed fragment showing attributes, repeated elements, and mixed content in one document.
XML input
JSON output
Look closely at the two tag values. The first item has an array because it had two tag children. The second has a bare string because it had one. Identical structure in the source produces different types in the output, and that is the single biggest hazard of this conversion.
The Single Element Ambiguity
Nothing in an XML document says whether an element is repeatable. Repeatability lives in the schema, and most documents arrive without one. A converter can only look at what is present, so one occurrence looks like a scalar and two look like a list.
Downstream code then breaks in a way that passes every test on the sample file and fails in production the first time a customer sends a document with only one item. There are three practical defences.
- Configure a forced array list, naming the elements that are always arrays regardless of how many occurrences appear. This is the correct fix when you know the schema.
- Force every repeatable looking element to an array unconditionally, which produces uglier JSON but is completely predictable.
- Normalise defensively in the consuming code, wrapping any non array value in a one element array before iterating.
Mapping Conventions Reference
| XML construct | Common JSON representation | Notes |
|---|---|---|
| Attribute | "@name": "value" | Prefix keeps attributes distinct from child elements |
| Text content of a leaf | "element": "value" | Collapsed to a plain value when there is nothing else |
| Text alongside children | "#text": "value" | Needed because the element also has real child keys |
| Repeated elements | Array of values or objects | Only produced when more than one occurrence is seen |
| Empty element | null or empty string | Converters differ, check which one yours emits |
| Self closing with attributes | Object holding only @ keys | No text key at all |
| Comment | Dropped | Rarely preserved, treat comments as lost |
| Processing instruction | Dropped | The XML declaration disappears with it |
| CDATA section | Plain string | The wrapper is transport syntax, not content |
Whitespace and Mixed Content
Pretty printed XML is full of whitespace text nodes: the newline and indentation between a parent tag and its first child are, strictly speaking, text content. Converters trim them, which is almost always what you want and is technically lossy for elements where whitespace is significant.
Mixed content is the genuinely awkward case. Document oriented XML lets text and elements interleave freely, and JSON has no way to express interleaving order.
Mixed content that JSON cannot represent faithfully
If your XML is document oriented rather than data oriented, JSON may be the wrong target entirely. Keep the markup as a string and parse it with an HTML or XML aware renderer instead.
Namespaces and CDATA
Namespaces exist so that two vocabularies can be mixed in one document without their element names colliding. A prefix such as dc: is bound to a URI by an xmlns declaration, and the prefix itself is arbitrary: what identifies the element is the URI it resolves to.
JSON has no namespace mechanism, so converters typically flatten. Either the prefix is kept as part of the key, giving dc:creator as a literal key name, or it is stripped entirely, giving creator. Stripping is tidier and risks collisions if two namespaces use the same local name. The xmlns declarations themselves usually survive as ordinary attributes, so you may see @xmlns:dc in the output.
CDATA sections are simpler than they look. A CDATA block is just a way of writing text that contains angle brackets and ampersands without escaping each one, commonly used for embedded HTML or scripts. It carries no meaning of its own, so in JSON it becomes an ordinary string and the wrapper disappears. If the original CDATA held markup, that markup is now a string inside your JSON and still needs escaping before you insert it into a page.
Converting legacy feeds into modern payloads usually leads somewhere next. See the full converter collection for JSON to XML to go back the other way, JSON to TypeScript to type the result before you consume it, and JSON to CSV when the feed items really wanted to be a spreadsheet all along.
Frequently asked questions
How do I convert XML to JSON?
Paste well-formed XML, select XML-to-JSON and inspect the converted output.
How are XML attributes represented?
Attributes become separate properties using the converter’s attribute naming convention.
Do repeated XML elements become arrays?
Repeated sibling names are collected as arrays; inspect the single-element case too.
How are mixed text nodes handled?
Mixed content needs review because JSON objects do not directly preserve interleaved text and element order.
Is XML uploaded?
No. Input is processed in this browser tab and is not uploaded by the tool. Copy and download are actions you control; ordinary page analytics do not receive tool input.