XML to YAML

Q: What happens to XML attributes?

Each element's attributes are gathered into a nested @attributes mapping on that element, matching the convention XML to JSON already uses, so <subscriber id="1"> becomes @attributes: id: "1" under subscriber.

Q: Does this handle CDATA sections?

Yes — a <![CDATA[...]]> section's content is read the same as ordinary text, so it lands in the same place an equivalent plain-text node would.

XML Input

YAML Output

The same tree, a friendlier syntax

XML and YAML both describe a nested tree of data, but XML spells it out with opening and closing tags while YAML uses indentation, which is why a config file migrated from XML to YAML usually reads shorter and less noisy on the page. This page walks the XML with the browser's own DOMParser and writes the resulting tree back out with js-yaml, the same library every other YAML tool on this site uses.

The mapping is the same one XML to JSON already uses on this site, just written to YAML instead of JSON: an element becomes a key, its attributes are collected under an @attributes key so they never collide with a child element of the same name, and a repeated sibling tag becomes a YAML sequence.

Every value in the output stays a string, because that is what it was in the XML — <rsrp>-92</rsrp> becomes rsrp: "-92", not the bare number -92. XML carries no type information of its own, so there is no safe way to guess that a leaf was meant to be numeric, and guessing wrong is worse than leaving it as text — see the FAQ below for what to do if you need real numbers.

Nothing leaves your browser. There is no upload, and the conversion happens entirely client-side.

Converting a document

Paste your XML – A single well-formed root element, the same requirement every XML parser has.
Watch it convert – YAML appears on the right as you type, after a short debounce.
Check the attributes – Each element's attributes land under its own @attributes mapping so they never clash with a child element that happens to share a name.
Copy or download – Download saves a .yaml file, ready to drop into a config directory.

Pro tip: if a leaf value needs to come out as a real YAML number or boolean rather than a quoted string, convert to JSON first and cast the fields you need in code — that is the point at which you actually know which strings were meant to be typed values.

A subscriber record, XML to YAML

The id attribute lands under @attributes, and every leaf value stays a quoted string — XML has no type information to say otherwise.

XML → YAMLConvert

subscriber.xmlXML

<subscriber id="1">
  <subscriberId>SUB-1001</subscriberId>
  <msisdn>447700900142</msisdn>
  <plan>Unlimited 5G</plan>
  <roaming>true</roaming>
</subscriber>

subscriber.yamlYAML

'@attributes':
  id: '1'
subscriberId: SUB-1001
msisdn: '447700900142'
plan: Unlimited 5G
roaming: 'true'

When you need this

Migrating a legacy config file to YAML

Older Java services, telecom network elements (HSS, MME, SGSN) and some CI systems still configure themselves from XML. Converting the file here gives you a starting point for a YAML-based config without retyping every setting by hand.

Turning an XML API response into a YAML fixture

Test fixtures and example payloads are often kept in YAML for readability even when the real API answers in XML. Convert a captured response here rather than hand-writing the equivalent structure.

Reviewing a SOAP or RSS payload in a shorter form

A deeply nested SOAP envelope or an RSS feed is easier to scan as YAML's indentation than as XML's open/close tag pairs, particularly when you just need to check which fields are present.

What this page does

Converts elements, attributes and repeated tags to YAML mappings and sequences.
Collects each element's attributes under @attributes so they never collide with a child element.
Keeps mixed text-and-element content under #text, the same convention XML to JSON uses.
Runs entirely in your browser via DOMParser — nothing is uploaded.

Questions people actually ask

Why are numbers and booleans quoted in the output?

Because XML has no type system — every leaf is text as far as the parser is concerned, so <roaming>true</roaming> becomes the YAML string "true", not the boolean true. Guessing which leaves were meant to be typed values is exactly the kind of silent assumption that corrupts data, so this page leaves that decision to you.

What happens to XML attributes?

Each element's attributes are gathered into a nested @attributes mapping on that element, matching the convention XML to JSON already uses, so <subscriber id="1"> becomes @attributes: id: "1" under subscriber.

How are repeated elements handled?

The first occurrence of a tag becomes a single mapping. As soon as a second sibling with the same name appears, it is promoted to a YAML sequence and every occurrence is added to it — a lone element and two repeated ones therefore come out shaped differently, which is worth remembering if code downstream expects a list either way.

Does this handle CDATA sections?

Yes — a <![CDATA[...]]> section's content is read the same as ordinary text, so it lands in the same place an equivalent plain-text node would.

Specifications and references

W3C XML – The official home of the XML specification
MDN DOMParser – The browser API this converter parses with
YAML 1.2.2 Specification – Defines the mapping and sequence forms this page writes
js-yaml – The YAML writer behind this page and every other YAML tool on this site