Guide · JSON & Data

How to Convert XML to JSON for Modern Apps

Updated 2026-08-10 · 4 min read

XML still arrives in 2026: SOAP envelopes, RSS and Atom feeds, SAML-adjacent blobs, vendor configs that never moved. Your app speaks JSON. The job is a one-off transform of a pasted document, not a new enterprise bus.

XML to JSON on DevOkk.com converts in the browser. No account. If the envelope might contain tokens, account numbers, or customer PII, do not drop it on a random upload converter. Browser-local is the safer default.

Why XML still arrives

Public APIs standardized on JSON. Internal and legacy systems did not get the memo. You will see:

  • A SOAP Envelope with Body and a vendor-specific child.
  • An RSS item with title, link, and description.
  • A config export with attributes (<env name="prod">).
  • A callback that is XML because the other party’s stack is 15 years old.

Pasting that into JSON Formatter fails, correctly. Tags are not curly braces. Convert, then use the JSON toolkit.

This article is not “XML is dead.” XML is good at documents, mixed content, and schemas that already exist. JSON is good at the objects your frontend already has types for. Convert when the consumer changes, not as a moral position.

What the mapping actually does

Elements become objects or arrays. Repeated sibling tags (<item> <item>) should become a JSON array. A single <item> might become an object. That inconsistency is the classic trap: your code does items.map and the converter emitted one object because the sample feed had one item.

Attributes must go somewhere. Common conventions: "@id": "88", or "id": "88" merged onto the element, or a nested "$": { "id": "88" }. There is no single correct JSON for XML attributes. Look at one converted element and write your mapper against that shape.

Text nodes and mixed content (<p>Hello <em>there</em></p>) do not have a lossless JSON equivalent that stays pleasant. Expect either a flattened string or a clumsy array of nodes. If mixed content matters, you may need to keep XML for that fragment.

CDATA should surface as a string. If you see the <![CDATA[ wrapper in the JSON, the parser did not unwrap it. Try again or strip it by hand for a one-off.

Attributes, repeating elements, and CDATA

Repeating elements. Convert a sample with two <order> nodes and a sample with one. If the output type flips between object and array, normalize in your code (const orders = Array.isArray(x) ? x : [x]).

Attributes versus children. <user id="9"><name>store-9</name></user> might become {"@id":"9","name":"store-9"} or {"id":"9","name":"store-9"}. Pick a convention and do not mix them in one mapper.

Empty elements. <flag/> might become null, "", true, or {}. Check.

Namespaces. xmlns and prefixed names can produce keys you did not expect (soap:Body, {http://...}Body). For a one-off paste, you often care about the local name. For a stable integration, keep the prefix so two Body elements from different namespaces do not collide.

None of this is a reason to upload the file to a cloud converter. It is a reason to look at the output.

A SOAP envelope or RSS item

You copy a SOAP fault from a log. It is XML. You need faultstring in a JSON ticket.

Paste the envelope into XML to JSON. Find the fault node in the result. If the JSON is one line, run it through JSON Formatter. If it is deep, use JSON Viewer. If you are explaining the envelope to someone who has never seen SOAP, the graph visualizer will show EnvelopeBodyFault faster than scrolling tags.

Second example: an RSS item.

<item>
  <title>Release 1.4</title>
  <link>https://example.com/rel/1.4</link>
  <guid isPermaLink="false">rel-1.4</guid>
</item>

After conversion, guid may be a string or an object with an isPermaLink attribute. That is the attribute convention showing up in a real feed. Fix the consumer, not the universe.

Strip live tokens from SOAP headers (wsse, session ids) before the snippet leaves your machine. Conversion is not redaction.

After you have JSON

The XML job is finished. The JSON job may not be. Format if you need to read it. View if you need a path. Minify if you are committing a fixture. Graph if the nesting was the original confusion.

If you are choosing formats rather than converting one file, read JSON vs XML vs YAML vs CSV. If the next paste is a .yml config, that is YAML to JSON, not this page.

Very large XML can exhaust the tab. Sample the feed. A browser converter is the wrong engine for a nightly 2 GB drop. Invalid XML (unclosed tags, truncated logs) should fail closed. Do not “fix” a truncated SOAP body by uploading it to a second site.

Convert one XML element, then the rest

Open XML to JSON with a non-sensitive sample. Convert one element, confirm attributes and arrays, then convert the real document if policy allows it in a browser. Continue with JSON Formatter if you need to read the result. Sibling converters and viewers live under JSON tools.

Frequently asked questions

Does XML to JSON require an account?

No. XML to JSON opens without an account. Paste the XML, convert it in the browser, copy the JSON, and close the tab.

Does the converter upload my XML?

XML to JSON is designed to process the text in your browser. The document is not sent to complete the conversion.

Should I convert a SOAP body that contains customer data?

Avoid pasting production tokens or PII into random websites. If you must transform a sensitive envelope, a browser-local converter is the safer default.

Why did attributes disappear or become keys?

Converters must pick a convention: attributes as @id keys, nested #text nodes, or flattened fields. Check the output against one element before you trust a whole feed.

Can I paste XML into JSON Formatter?

No. The formatter expects JSON. Convert first, then format, view, or minify the result.

What about namespaces and CDATA?

Namespaces often become prefixed keys or get stripped depending on the parser. CDATA should become a string. If either looks wrong, inspect a single node before converting a large file.

More reading that links back to the same tools and workflows.