XML to JSON Converter
Convert XML to JSON format instantly. Paste or upload your XML file.
Upload an XML or TXT file (max 5MB)
Conversion Options
How to Use:
- Paste your XML content in the left textarea or upload an XML file
- Customize conversion options if needed
- Click "Convert to JSON" to transform your XML
- Copy the JSON output or download it as a file
- Use "Format JSON" or "Minify JSON" to adjust the output
How This Tool Resolves the XML-Attribute Problem
JSON has no equivalent of an XML attribute — every value is just a key. There's no single agreed-upon convention for representing <user id="42">Alice</user> in JSON, and different tools make different choices. This converter's specific choice: attributes become object keys prefixed with @ (so id="42" becomes "@id": "42"), and when an element has both attributes and text content, the text is placed under a special #text key alongside the attributes. So the example above converts to {"user": {"@id": "42", "#text": "Alice"}}. If you're feeding this output into code that expects a different convention (some libraries use $, an _attributes sub-object, or drop attributes into the parent object without a prefix), you'll need to adjust your consuming code or the JSON shape to match — there's no universal standard here to rely on.
A Quirk Worth Knowing: Single Child Elements Still Become Arrays
Many XML-to-JSON conventions only wrap repeated sibling elements in an array when there's more than one of them, collapsing a lone child element directly into its parent. This converter does not do that: any child that is itself an element (not plain text) gets pushed into an array, even when it's the only child present. So <a><b>1</b></a> converts to {"a": [{"b": "1"}]} — an array with one entry — rather than the possibly-more-intuitive {"a": {"b": "1"}}. If your downstream code assumes a nested object and instead finds a one-item array, this is why — you'll need to index into [0] or adjust however you consume the field. A child that's plain text (no attributes, no nested elements) does collapse to a bare string as you'd expect: <a>hello</a> becomes {"a": "hello"}.
Two more specific behaviors worth knowing before you rely on this converter in a pipeline: an element with no attributes and no children — <empty/> — becomes {"empty": null}, not an empty string or empty object. And whitespace-only text nodes (the indentation between your tags, if your source XML is pretty-printed) are stripped and ignored rather than showing up as stray empty strings in the output.
Namespace Prefixes Are Kept Literally Unless You Strip Them
If your XML uses namespace prefixes (<soap:Envelope>), leaving "Strip Namespaces" unchecked keeps the full prefixed name as the literal JSON key, colon included — "soap:Envelope" is a perfectly legal JSON object key even though it wouldn't be a valid JavaScript identifier you could access with dot notation (you'd need obj["soap:Envelope"] rather than obj.soap:Envelope). Checking "Strip Namespaces" removes everything before the colon on both element names and attribute names, which produces cleaner, dot-accessible keys but also means you lose the ability to tell which namespace a same-named element originally belonged to if your source XML mixed multiple namespaces with overlapping local names.
Frequently Asked Questions
Why did my single nested element turn into a one-item array?
This converter always wraps element children (not plain text children) in an array, regardless of how many there are — it doesn't special-case the "only one child" scenario the way some other XML-to-JSON tools do. Index into position 0 if you expected a plain object instead.
What happened to my XML attributes — where did the "@" come from?
Attributes are converted to JSON keys prefixed with "@" (e.g. an "id" attribute becomes "@id"). This is one of several conventions used across different XML-to-JSON tools; there's no universal standard, so check whether your consuming code expects this exact prefix.
Why is an empty XML tag showing up as null instead of an empty string?
An element with no attributes and no child content or text converts to JSON null, which distinguishes "explicitly empty" from a missing key — but be aware this happens even for self-closing tags that some other systems might expect to become "" instead.
Should I strip namespaces before converting?
Strip them if you just need clean, dot-accessible property names and your XML doesn't rely on namespaces to disambiguate same-named elements. Keep them if the same local element name appears in more than one namespace in your source document — stripping would make those collide under one JSON key.
Can this validate my XML against a schema before converting?
No — it uses the browser's DOMParser to confirm the XML is well-formed (proper nesting, one root element, valid syntax), which will catch malformed XML, but it does not check conformance against an XSD or DTD schema.