メインコンテンツへ移動
ToolsByUs

XML to YAML

This converter turns an XML document into readable YAML in your browser. Attributes become keys prefixed with @, an element's text becomes #text when it shares the element with attributes or children, and repeated sibling elements become YAML sequences. Values stay strings, so a postal code survives intact, and nothing is uploaded.

端末内で処理

このツールの画面は英語表記です。

以下の解説は英語のみでご覧いただけます。

XML to YAML explained

XML carries values in three places — attributes, text content and child elements — and YAML has room for all three in one mapping, provided each gets a name that cannot collide with the others. That is the whole convention this converter applies: id="bk101" becomes the key "@id", the text inside an element becomes "#text" when it needs a home of its own, and child elements become keys whose values are mappings or lists. The prefixes look like noise until an element has an attribute, a child and text at once — then they are the only reason the round trip can be lossless.

The YAML style is the site's house style: two-space indentation, sequence dashes aligned with their parent key rather than tucked underneath, and quoting only where the plain form would be misread. That last rule does real work here. XML text is untyped, so 44.95 is a string, and the emitter writes it as "44.95" precisely so a YAML parser will not re-infer a number from it. The result is a document that round-trips: XML to YAML and back arrives with the same values, the same attributes and the same structure it started with.

Everything runs in this browser tab. The XML is parsed by an in-page engine and the YAML is emitted from the parsed tree; neither touches a network — open DevTools, watch the Network panel stay silent, and the claim checks itself.

To send the result back the other way, the YAML to XML converter honours the same @ and #text conventions, so nothing needs renaming by hand.

New to reading YAML output? The YAML basics guide explains indentation, quoting and the scalar rules the emitter follows.

How the conversion actually works

The document is tokenised once into a tree of elements, attributes and text, and the YAML emitter only ever sees that tree — so formatting quirks in the source (ragged indentation, attributes split across lines) cannot leak into the output. The tree either fits one document with one root or it does not, and the converter says which.

  • Parse: a single-pass tokenizer reads elements, attributes, text, comments and CDATA; mismatched or unclosed tags are rejected with a line number.
  • Convert: each element becomes a mapping — attributes as "@key" entries, text as "#text", child elements as nested keys.
  • Collect: repeated sibling elements are gathered into one list, so <book> appearing ten times becomes a ten-item sequence.
  • Emit: the tree is serialised as YAML at two-space indent, with quotes only where a value would otherwise be misread.

How XML features land in YAML

Every feature of the source document has a reserved seat in the output, and the seats are chosen so two features can never fight over one key. The table shows the mapping on the shapes that actually appear in real documents — an element with an attribute, an element with children, an element that repeats.

XML constructYAML produced
<book id="bk101">a book mapping with "@id": bk101
<price>44.95</price>price with "#text": "44.95"
ten <book> siblingsone book key whose value is a ten-item list
<debug/> (empty)debug: {} — present, explicitly empty

Why #text exists, and when it appears

An element whose content is only text — <price>44.95</price> — could become the plain mapping price: 44.95, and for elements with no attributes and no children, that is effectively what you get to read. But the moment an element also carries an attribute or a child, its text needs a key that no attribute name and no child element name can ever occupy. #text is that key. It appears only when text must share its element with something else, which keeps ordinary output clean while making complicated output unambiguous.

  • Text-only elements keep their content readable on one line.
  • Mixed elements — attributes plus text, or children plus text — move the text under "#text".
  • Entities in the source text are carried verbatim; the parser is not a validating parser and does not rewrite them.

Values, types and the round-trip guarantee

XML text is strings, and the emitter treats it that way: nothing is coerced to a number or a boolean on the way through. The visible consequence is quoting — 44.95 is written as "44.95" because an unquoted 44.95 would re-read as a number in YAML, and a postal code like 02134 would lose its leading zero the same way. Values that cannot be mistaken for anything else, like bk101, are emitted plain. Convert the result back with the site's YAML to XML converter and the document you get is the document you started with, byte for byte where it matters: names, attributes, text and structure.

  • No type inference: text crosses as text, so precision and leading zeros survive.
  • Number-lookalike strings are quoted on output, which is what makes the round trip lossless.
  • Whitespace inside a text node is preserved; whitespace between elements never becomes data.

Frequently asked questions

Does converting XML to YAML upload my document anywhere?

No. Parsing and YAML generation both run inside this browser tab with code that was loaded once at page open. There is no upload endpoint, and the page is served with a Content-Security-Policy whose connect-src is 'self', so the browser would refuse any outbound request regardless of the code. Watch the Network panel in DevTools while you convert — it stays silent, and that is the verifiable version of this promise.

What do the @ and #text prefixes in the output mean?

They record where each value came from in the XML. A key like "@id" holds an attribute — id="bk101" in the source — and "#text" holds an element's own text when that element also has attributes or children. The prefixes guarantee no collision: an attribute named price and a child element named price cannot both map to the same key, and the YAML reader can always tell which kind of value it is looking at.

How are repeated elements handled?

Sibling elements that share a name are collected into one YAML sequence: ten <book> children become a single book key whose value is a ten-item list, in document order. Elements that appear once stay plain mappings. This is the standard XML-to-data convention, and it is what makes the output natural to iterate in code — each list item is one record, with attributes and children folded inside it.

Why is 44.95 written with quotes in the YAML output?

Because XML text is untyped, the value is the string 44.95 — and an unquoted 44.95 in YAML would be re-read as a number by every parser downstream. Quoting number-lookalike strings is the emitter's way of preserving what the source actually said, and it is the same rule that keeps a postal code like 02134 from losing its leading zero. Values that cannot be misread, such as bk101, are emitted without quotes.

Which parts of the XML document are ignored?

Comments, the DOCTYPE declaration and processing instructions are skipped, since none of them carry element data. Everything structural is kept: elements, attributes, text and CDATA sections. The converter does require a single root element — a paste with two top-level elements is rejected with the second element's name and line number, because two roots are two documents and merging them silently would fabricate a structure that was never there.

What happens to empty elements like <debug/>?

An empty element becomes an explicit empty mapping — debug: {} — rather than vanishing, so the key survives and a consumer can still tell the field was in the document. An element written with separate open and close tags but no content, <note></note>, lands in the same place: the structure says the element existed, and only the content was empty. Nothing is invented to fill it.

ToolsByUs team · How we check our tools