Convert XML to YAML

XML spends roughly half its characters saying where an element ends. YAML says it with indentation, so the same document comes out substantially shorter and each nesting level is one visual step rather than a matched pair to scan for. On a Maven pom or a web.config that is the difference between scrolling and reading.

The structure is unchanged. Every element becomes a key, its children become the mapping beneath it, and text becomes the value. Nothing is reordered and nothing is summarised, so what you are looking at is the same document with the punctuation removed — which is exactly what you want when the purpose is to understand what the file says.

Attributes come across as keys prefixed with @, and an element that carries both attributes and text stores that text under the key #text. Both get written with quotes around them, because YAML treats @ as a reserved indicator at the start of a plain scalar and # as the start of a comment.

It looks like noise and it is correctness. If you edit the file by hand, keep those quotes: removing them produces YAML that either fails to parse or, in the case of #text, silently turns the rest of the line into a comment and loses the value. The same applies if you retype a key while reshaping the output into a values file.

This is the strongest reason to make the conversion. Diffing XML is miserable because a change one level deep shows as several lines of tags, and reformatting by a tool rewrites the whole file. Converting both versions and diffing the YAML shows the changed values on their own lines with their key path visible above them.

One caveat makes or breaks it. Because a single repeated element becomes a mapping and two become a list, a version that added a second dependency changes the shape of that branch and not just its contents, so the diff shows the whole block as rewritten. That is not the converter losing information — it is the shape genuinely changing — but knowing it in advance saves you from reading a large diff as a large change.

Prefixes are preserved as part of the key name, so a document using soap: or xsi: produces keys containing a colon. The writer emits those unquoted, and they read back correctly through the same parser. The namespace declarations themselves survive as attributes, so a default xmlns arrives as a quoted "@xmlns" key on the root.

A colon inside an unquoted key is the kind of thing worth tightening by hand before the file travels. If the YAML is going to be read by another tool, quote those keys yourself — it costs nothing and removes a class of problem that only appears at the point where somebody else parses the file. Nothing resolves prefixes to their namespace URIs, so two documents using different prefixes for the same namespace produce YAML that does not diff cleanly against each other.

Values that read as numbers are parsed, in element text and in attributes alike. A Maven version of 4.13.2 stays a string, because it has two dots and cannot be a number, and so does an address or a path. A version attribute written 1.0 becomes 1, and a zero-padded value written 007 becomes 7.

On a config that is read rather than executed the damage is limited to how the value looks, and it still matters: a schema version rendered as 1 instead of 1.0 in a review is a value somebody will question or, worse, copy. Scan the numeric-looking values in the output once. If the YAML is going anywhere except a human eye, quote the ones that were meant as identifiers.

A value containing newlines is written as a block scalar — a pipe character with the text indented beneath it — which keeps it readable rather than escaping it onto one line. A long single-line value is written as-is without wrapping. Both are the right choices for a file meant to be read.

An empty or self-closing element becomes an empty string, written as a pair of quotes. XML does not distinguish an empty element from one containing nothing, so no information is lost, but an empty string is visually easy to miss in a long file — if you are auditing a config for unset values, search for the empty quotes rather than trusting the eye.

XML supports comments, YAML supports comments, and none of yours survive. The parser discards them and nothing writes them back. On a payload that is irrelevant; on a build file it is the single largest loss, because the comment above a pinned dependency version is usually the only surviving record of why it is pinned.

The working arrangement that avoids the trap is to treat the YAML as a reading copy and keep the XML as the source. If the YAML is instead going to become the source — a genuine migration into Ansible or a Helm chart — schedule the pass that copies the comments across as part of the work, before the XML is deleted and the reasoning is gone with it.

A converted config is not yet a values file or a variable set. It carries XML artefacts — the @ keys, the #text keys, a namespace declaration on the root, and possibly a ?xml key from the declaration line — which are meaningless to whatever you are feeding. Deleting them is the first pass.

The second is naming. XML element names are often verbose in ways that made sense with a schema behind them, and a YAML config usually wants them shorter and flatter. Both passes are manual and both are the actual migration; the conversion just gets you a legible starting point instead of a wall of tags.

Convert when the goal is to understand, review or compare: the YAML is shorter, the structure is obvious, and the whole thing runs in your browser in the time it takes to drop the file. It is a good habit for any config file you have been handed and have to reason about before changing.

Do not convert when the file is validated by a schema, signed, or consumed by a tool that reads XML. The XML is the artefact in that case, and a YAML copy is a second version of the truth that will drift from the first. Read it as YAML, change it as XML.