XML to YAML Converter

The usual reason to convert XML to YAML is migration. A legacy system emits XML — a Spring context, an Ant build, a Maven POM, an RSS feed, an old Java properties export — and the replacement expects YAML, because everything written in the last decade expects YAML. Doing that by hand for a file of a few hundred elements is tedious and error-prone, and the interesting part of the job is deciding what the target structure should be, not retyping values.

This converter maps XML into a data model first, applying the same conventions as the XML to JSON tool — attributes become @name keys, text becomes #text, repeated elements become sequences — then emits that model as block-style YAML. It runs entirely in your browser in a Web Worker.

Reading the output

Three things in the YAML will look unusual at first, and all three come from XML features that YAML has no direct equivalent for:

• Keys beginning with @ are XML attributes. They appear quoted, as "@href": …, because @ is a reserved indicator character in YAML and a bare key cannot start with it. The quoting is required, not stylistic.
• A key named #text holds element text that had to coexist with attributes on the same element. It is quoted for the same reason — # starts a comment in YAML.
• Repeated elements become a sequence under a single key. Two <item> elements under <channel> become a list of two mappings, which is exactly the shape you want. An element that appears only once becomes a plain mapping, not a one-item list — the same cardinality trap the JSON conversion has, and worth checking before you write code against the result.

Beyond those, the output is ordinary YAML: nesting by indentation, no braces, values unquoted where it is safe. Long text that contained newlines is emitted as a literal block scalar with |, which is a real improvement over the same content sitting inside an XML element.

Making the result idiomatic

A mechanical conversion produces correct YAML, not good YAML. Three edits typically turn it into something you would be happy to commit.

First, fold attributes into plain keys. In XML the choice between <item id="7"/> and <item><id>7</id></item> is a modelling decision with real consequences; in YAML there is no such distinction, so "@id": "7" should almost always just become id: 7. Renaming those keys is the single biggest readability win.

Second, fix the types. Every value arrives as a string, because XML has no types without a schema. In YAML, replicas: "4" and replicas: 4 are different values and the consuming application will care. Unquote the numbers and booleans you know are numbers and booleans — and only those.

Third, collapse redundant nesting. XML frequently wraps a collection in a container element, as in <lines><line/><line/></lines>. That produces lines: { line: [ … ] } in YAML, where lines: [ … ] says the same thing. YAML sequences carry their own name, so the wrapper is pure noise.

What does not come across

Comments are discarded. This is the ironic one, since YAML supports comments perfectly well — the loss happens in the intermediate data model, which has no place to keep them. If the XML contains comments worth preserving, copy them across by hand afterwards.

Namespace prefixes survive only as literal text in key names: <atom:link> becomes the key "atom:link", and the xmlns:atom declaration becomes an ordinary "@xmlns:atom" key. The binding between prefix and URI, which is what actually gives a namespace its identity, is not modelled. Two documents using different prefixes for the same namespace produce different YAML.

Processing instructions and the DOCTYPE are dropped. Mixed content — text interleaved with child elements — loses its interleaving: the text is joined into a single #text value and the elements are listed separately. Document-oriented XML does not convert usefully; data-oriented XML, which is what most people are converting, does.