Convert XML to JSON in your browser without leaking the payload
Plenty of systems still emit XML — SOAP responses, RSS and Atom feeds, sitemap files, Maven POMs, Spring and Android configs, healthcare and finance exports — while the services that consume them speak JSON. Rewriting those documents by hand is slow and error-prone the moment attributes, namespaces and repeated elements stop mapping cleanly onto object keys. This converter turns pasted XML into structured JSON instantly and locally, so a vendor feed full of identifiers you are not allowed to upload never touches a third-party form. Use it when you are onboarding a supplier export, stubbing a JSON fixture from a legacy SOAP sample or eyeballing the shape of an unfamiliar feed before you write a parser around it.
Conversion workflow
- Paste the XML or import a .xml, .rss or .svg file.
- Choose whether attributes and type coercion are on.
- Convert and inspect how repeated tags became arrays.
- Format the JSON and lock it into a fixture before you build against it.
How the mapping works
Each element becomes a JSON object. A leaf element with only text collapses to that text value, while an element that also carries attributes keeps its value under a #text key so nothing is lost. Attributes are emitted as @-prefixed keys, which is the widely understood convention used by most XML-to-JSON tooling, so the result reads predictably to anyone who has worked with these conversions before. When a parent holds several children with the same tag name, those siblings collapse into an array; a single occurrence stays a scalar or object. That last rule is the one that trips people up, so review any field that is logically a list before you wire it into code.
Mind the type fidelity gap
XML is essentially stringly-typed: a number, a boolean and a date all look like text inside a tag, whereas JSON distinguishes numbers, booleans and null natively. With the convert option enabled, this tool promotes text that is exactly a number or true/false to the real JSON type while deliberately leaving anything with leading zeros, plus signs or thousands separators as a string — because 00713 is almost always an identifier, not the integer seven hundred and thirteen. If your downstream contract is strict, cast in the consumer rather than trusting any converter to guess, and pin the expected types in a schema so a future feed change surfaces in review instead of in production.
Validate, format and pin the result
Once you have JSON, prettify it with the JSON Formatter, confirm it parses cleanly in the JSON Validator and capture the expected shape with the JSON Schema Generator so the next person inherits a contract rather than a guess. When you need to go the other way or keep both representations in sync, the JSON ⇄ XML Converter handles the reverse direction, and JSON Diff will flag drift between two converted snapshots after a feed changes.
Production checklist
Strip secrets and tokens before sharing converted output even though processing is local, since the JSON will likely be pasted into a ticket or PR. Decide up front how namespaced elements should appear — many pipelines flatten the prefix, which can collide if two namespaces share a local name. Keep a small golden sample that includes attributes, an empty element and a repeated tag so the awkward cases are exercised every time you regenerate fixtures. Document whether your consumer expects single-item lists as arrays, because that is the most common source of "works on my machine" parsing bugs when XML feeds grow from one row to many.
Further reading
For the bigger picture, this guide pairs with a short series on working with these two formats: XML vs JSON: the practical differences weighs up when to use each, how XML maps to JSON covers the attribute, array and type rules in depth, and the two most common real-world sources get their own walk-throughs in turning SOAP XML into JSON and reading RSS and Atom feeds as JSON.