Saltar al contenido principal
ToolsByUs

YAML to XML

This converter renders YAML mappings and sequences as XML in your browser. Mappings become nested elements, sequences become repeated elements, and scalar values become text content, with keys sanitised to legal tag names and text escaped per XML 1.0. A @-prefixed key becomes an attribute. Nothing is uploaded.

Solo local

La interfaz de esta herramienta está en inglés.

La guía de abajo solo está disponible en inglés.

YAML to XML explained

YAML and XML both express trees, so the conversion is mostly vocabulary: a mapping becomes an element with children, a sequence becomes one element repeated, and a scalar becomes text content. The one thing YAML has no way to say is a root element name — an XML document needs exactly one — so the converter supplies <root> as the document element and nests your document inside it. A top-level list becomes <root> holding one repeated element per item; a top-level mapping keeps its keys as element names one level down.

The strict side of the bargain is XML's name rules, and the converter enforces them rather than hoping: every key becomes a legal tag name, with characters outside the allowed set replaced by underscores and a leading underscore added where a name would start with a digit. Text is escaped per XML 1.0 on the way out — &, < and > in content, plus the double quote inside attribute values — so any standards-compliant parser can read the result. Values cross over as their exact characters; there is no numeric coercion step to second-guess a port number or a version string.

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

Checking the round trip takes one paste, because the XML to YAML converter reads the @ and #text conventions back in the other direction.

If the input side is the shaky half — indentation, quoting, type inference — the YAML basics guide covers the rules this parser expects.

How the conversion actually works

The document is parsed once into plain data, and the XML writer only ever sees that data — never the original text. That separation is what makes the rules below predictable: the writer cannot be surprised by YAML syntax, and the parser cannot be influenced by what the XML will look like. Each stage has one job and one output.

  • Parse: the YAML is read into mappings, sequences and scalars — the everyday core, with comments allowed and anchors or aliases outside the supported set.
  • Wrap: the document is placed inside a single <root> element, because XML requires exactly one root and YAML has no name to offer for it.
  • Render: mappings nest as child elements, sequences become repeated elements, and scalar values become the text content of the element named by their key.
  • Escape and indent: text gets the three mandatory XML escapes, attributes additionally escape quotes, and the document is pretty-printed at two spaces per level.

The tag-name policy, precisely

XML 1.0 names may start with a letter, underscore or colon and may continue with digits, hyphens, dots and colons; everything else is out. YAML keys are freer than that, so every key is checked and repaired: a space becomes an underscore, a leading digit earns a leading underscore, and a key that was already legal — including kebab-case like content-type — passes through untouched. Notably, a dot is a legal character inside an XML name, so a key like address.city becomes one element named address.city here, not a nested pair; nesting is expressed by the YAML structure itself, not by punctuation in the key.

YAML keyElement emittedWhy
role<role>already legal — passed through
first name<first_name>space replaced with an underscore
2fa<_2fa>names cannot start with a digit
content-type<content-type>hyphens are legal in XML names

Attributes, text and the @ convention

YAML has mappings where XML has attributes, and the bridge is the same convention the site's XML to YAML converter uses in reverse: a key beginning with @ becomes an attribute of its element, and the special #text key carries the element's own text when it also has attributes or children. A record written as {"@id": bk101, "#text": A guide} comes out as <book id="bk101">A guide</book> when placed under a book key. The convention is optional — plain keys and values need none of it — but it means the full surface of XML is reachable from plain YAML data without a second syntax.

  • @sku: A-1 becomes the attribute sku="A-1" on the enclosing element.
  • #text holds an element's own text, so attributes and content can coexist without colliding.
  • A null value is omitted entirely; an empty string becomes a self-closing element, because the two are different in YAML and the output respects that.
  • Numbers and booleans are stringified — 8080 arrives as the text 8080, true as the text true.

Edges the converter will not paper over

Three inputs get named errors or explicit, documented behaviour instead of a shrug. YAML features this converter's parser deliberately does not support — anchors and aliases, merge keys, directives — are rejected with an error rather than half-implemented, because a converter that guesses at anchor expansion invents content. A multi-document stream converts using its final document, documented here rather than left to discovery. And a document that is only a scalar still converts: it becomes the text inside <root>.

  • Anchors, aliases and merge keys: rejected with a named error, not expanded by guesswork.
  • Multi-document streams: the last document wins, and the behaviour is documented here rather than discovered by accident.
  • Tabs used for indentation: rejected at parse time, per YAML's own rules.

Frequently asked questions

Does converting YAML to XML upload my file anywhere?

No. Parsing and XML generation both run inside this browser tab with JavaScript that was loaded once when the page opened. There is no API route to send data to, and the page's Content-Security-Policy sets connect-src 'self', so the browser itself would refuse any outbound request. You can verify both claims in DevTools: the Network panel shows no request when you convert.

Why is my XML wrapped in a <root> element?

XML requires exactly one root element, and YAML offers no name for one — a YAML file is just data. The converter therefore supplies <root> as the document element: a top-level sequence becomes <root> with one repeated element per item, and a top-level mapping keeps its keys as child elements one level down. If you need a different root name, put your data under that key in the YAML and it becomes the element you named.

How are YAML keys turned into legal XML tag names?

Each key is checked against the XML 1.0 name rules and sanitised only where it fails: characters outside letters, digits, underscore, hyphen, dot and colon become underscores, and a name starting with a digit gets a leading underscore. Keys that were already legal pass through untouched. A dot is legal inside an XML name, so address.city becomes a single element of that name — nesting comes from the YAML structure, not from dots in keys.

Can YAML produce XML attributes and text content?

Yes, via the @ convention: a key beginning with @ becomes an attribute of its element, and the reserved #text key carries the element's own text. Writing "@id": bk101 under a book key yields <book id="bk101">, and adding "#text": A guide puts text inside it. It is the same convention the site's XML to YAML converter emits, so a document can cross formats in both directions without renaming anything by hand.

What does the converter do with numbers, booleans and empty values?

Scalars are stringified, because XML text has no types: 8080 becomes the text 8080 and true becomes the text true, with no formatting changes. A null value produces no element at all, while an empty string produces a self-closing element — the distinction YAML makes is preserved in the output. Text is escaped on the way out (&amp;, &lt;, &gt;, and &quot; inside attributes), so parsers read back exactly the characters you wrote.

Which YAML features does the parser support?

The everyday core: mappings, sequences, plain and quoted scalars, comments, and the usual scalar types. Anchors and aliases, merge keys and directives are outside the supported set and are rejected with a named error rather than guessed at — silent anchor expansion would invent content that was never in your file. For a multi-document stream, the final document is the one converted, which the page documents rather than leaving to discovery.

ToolsByUs team · How we check our tools