Convert XML to YAML Online

Q: How are XML attributes represented in the YAML output?

By default each attribute becomes a key prefixed with @ on the parent mapping. becomes server: with @port: "8080" and @secure: "true" as children. Two alternatives are available in settings: nest attributes under an _attributes: block (useful for Ansible's community.general.xml filter), or merge them directly as regular keys (loses the distinction between attributes and child elements but produces the flattest output).

Q: What happens to CDATA sections and entity references?

CDATA ( ) content drops into YAML as a plain string. If the content contains characters that would otherwise need YAML escaping (:, #, leading -, leading ?), the converter wraps the value in a literal block scalar (|) or folded scalar (>) to preserve it verbatim. Standard XML entity references (<, &, —) are resolved to their character values before YAML emission.

Q: Can the converter handle large XML files like a 50 MB Spring config or SOAP log?

Up to about 10-15 MB it stays interactive. Beyond that, browser memory and the single-threaded JS event loop dominate — Chrome and Firefox will still finish but the editor freezes for a few seconds. For one-off conversions of multi-megabyte XML, that's fine. For repeated batch work, the command-line tooling (Python xmltodict + pyyaml, or yq -p xml -o yaml) is the right scale-out path; xconvert is positioned for interactive, on-demand jobs.

Q: Is the conversion reversible — can I get my XML back?

Mostly yes, if you keep the default @-prefix attribute mapping and preserve namespace prefixes during the forward conversion. The YAML to XML converter recognizes the @-prefix convention and rebuilds elements with their attributes. What does not survive a round-trip: processing instructions ( ), DTD declarations, comment positioning, the order of attributes within an element, and the original XML's exact whitespace. For round-trip-critical workflows (digital signatures, canonical XML), don't convert — keep the XML.

Q: How does this compare to running yq -p xml -o yaml locally?

yq (the mikefarah Go reimplementation) is the gold standard for batch XML→YAML and scripting; install it once and pipe files through. xconvert covers the interactive case: paste a SOAP response from a browser DevTools network tab, eyeball the converted YAML, copy it into a pull-request description. The two are complements rather than competitors — yq for pipelines and CI, xconvert for ad-hoc inspection. If your input is already valid YAML and you only need linting, use the dedicated validate YAML page; for XML well-formedness checks, validate XML.

Upload your XML file and convert it to YAML for easier reading and editing, then download the YAML result instantly.

Input

Output

Read Only

How to Convert XML to YAML Online

Paste or Load Your XML: Type or paste XML into the Input panel on the left, or drag-and-drop a .xml file onto it. The editor validates as you type and flags unclosed tags, mismatched braces, and bad entity references inline.
Pick Output Format (YAML): The Input and Output panels each carry JSON / YAML / XML tabs along the top. Confirm the Output tab is set to YAML (the bidirectional ⇄ arrow swaps which side is source and which is target if you want to round-trip later).
Tune Attribute and Indent Behavior (Optional): Decide how XML attributes should map — the default @-prefix convention turns <server port="8080"> into @port: "8080", while a nested _attributes block keeps them grouped. You can also strip namespace prefixes (soap:Envelope → Envelope) and force-quote all scalars to prevent YAML's type inference from turning true, yes, or 01:30 into a boolean, string, or sexagesimal number.
Convert and Copy: The output panel renders YAML the instant your XML parses cleanly. Use Copy to push it to the clipboard or Read Only to lock the output while you compare side-by-side. Everything runs in your browser session — no upload, no account, no watermark.

Need the reverse trip? Use the YAML to XML converter. For other targets try the XML to JSON converter or the YAML to JSON converter.

Why Convert XML to YAML?

XML (1998, W3C) and YAML (1.0 published January 2004; current spec 1.2.2, October 2021) solve the same problem — serialize hierarchical data — with opposite priorities. XML is verbose but unambiguous, with tags, attributes, namespaces, and schemas designed for document interchange between heterogeneous systems. YAML is whitespace-driven and reads almost like a bulleted list, which is why every modern config tool from Kubernetes to GitHub Actions picked it over XML. Converting XML to YAML is the practical first step when migrating off SOAP envelopes, Spring XML beans, Ant builds, or legacy Maven pom.xml snippets.

Kubernetes and Docker Compose migrations — Kubernetes manifests, Helm values files, and docker-compose.yml are YAML-only. Teams modernizing XML-defined deployment descriptors (legacy WebSphere, JBoss, or Tomcat server.xml) into container manifests start by converting the structure, then refactor against the Kubernetes API schema.
Ansible and SaltStack playbooks — Both default to YAML. Operations teams converting XML-based inventory or host definitions often run the data through a converter first so they only have to rewrite the logic, not the shape.
Spring Boot config consolidation — Spring still parses applicationContext.xml, but application.yml is the idiomatic modern choice and Spring Boot's @ConfigurationProperties binds to it cleanly. Converting bean definitions to YAML cuts file sizes 30-60% and makes pull-request diffs readable.
CI/CD pipeline rewrites — Migrating Jenkins config.xml jobs or Bamboo plans to GitHub Actions, GitLab CI, or CircleCI requires a YAML pipeline definition. Converting the XML is the structural starting point.
SOAP-to-REST or SOAP-to-event-stream gateways — When an integration team consumes a SOAP response and re-emits it onto a Kafka topic or OpenAPI-spec'd REST endpoint, normalizing to YAML (or JSON) inside the gateway simplifies the message contract.
Documentation and code samples — Sample configs in technical docs read more cleanly as YAML. Converting an existing XML example for blog posts, internal wikis, or training materials saves rewriting by hand.

XML vs YAML — Format Comparison

Property	XML	YAML
First released	1998 (W3C Recommendation)	2004 (YAML 1.0); current spec 1.2.2 (2021)
Syntax model	Tag-based, opening + closing elements	Indentation-based, whitespace-significant
Attributes	Native on every element	No native concept (convention: `@` prefix or `_attributes` block)
Namespaces	Full support with prefixes + URIs	None
Data typing	Everything is a string until parsed by an XSD	Native scalars: string, int, float, bool, null, timestamp
Comments	`<!-- comment -->`	`# comment`
Schema validation	XSD, DTD, RelaxNG	JSON Schema (YAML 1.2 is a JSON superset)
Mixed content	Yes (`<p>text <b>bold</b> more</p>`)	Not supported — represented via `_text`/`#text` keys
Anchors / reuse	Not built-in (requires XInclude)	Native anchors (`&`) and aliases (`*`)
Multi-document files	Single root element required	`---` separates multiple documents per file
File extensions	`.xml`	`.yaml` (canonical), `.yml` (common)
Typical size	Verbose — closing tags repeat the name	30-60% smaller for the same data
Primary ecosystem	SOAP, legacy enterprise, document publishing	DevOps, Kubernetes, CI/CD, cloud-native config

Attribute, Namespace, and Mixed-Content Handling

The trickiest part of any XML→YAML transformation is the structural mismatch on three points where XML is strictly more expressive than YAML.

XML feature	YAML representation	Recommended setting
Attributes (`port="8080"`)	`@port: "8080"` key on the parent mapping	`@`-prefix (compact, widely recognized)
Attributes (alt)	Nested under `_attributes:` block	Use when downstream tool expects it (some Ansible filters)
Namespaces (`soap:Envelope`)	Strip → `Envelope`, or keep → `soap:Envelope`	Strip for config use cases; preserve for round-trip
Mixed content (`<p>Hi <b>there</b></p>`)	`_text: "Hi"` alongside child keys	Reconsider YAML — JSON or keeping XML may fit better
Repeated siblings (`<item>A</item><item>B</item>`)	YAML sequence `- A\n- B`	Automatic — no setting needed
CDATA sections	Block scalar (`	`or`>`)
Empty elements (`<enabled/>`)	`null`, `""`, or `{}`	`null` by default; switch if your parser is strict
Processing instructions (`<?xml-stylesheet?>`)	Not representable	Dropped — note in commit if round-trip matters

For document-oriented XML (XHTML, DocBook, TEI) with heavy mixed content, YAML is the wrong target. JSON via XML to JSON converter preserves the structure more faithfully, or keep the source as XML and validate against an XSD instead.

Frequently Asked Questions

Does my XML data leave the browser?

No. The converter runs entirely client-side in JavaScript. Your XML never hits an xconvert server, which is why it works on internal API responses, proprietary Spring configs, and SOAP envelopes with credentials baked in. There is also no file-size cap imposed by a server tier — the practical limit is your browser's memory, typically comfortable up to 10-15 MB of XML.

How are XML attributes represented in the YAML output?

By default each attribute becomes a key prefixed with @ on the parent mapping. <server port="8080" secure="true"> becomes server: with @port: "8080" and @secure: "true" as children. Two alternatives are available in settings: nest attributes under an _attributes: block (useful for Ansible's community.general.xml filter), or merge them directly as regular keys (loses the distinction between attributes and child elements but produces the flattest output).

Should I strip XML namespaces or keep them?

Strip them for Kubernetes manifests, Ansible playbooks, Spring application.yml, and most application config — the namespace was XML plumbing the target tool doesn't need. Keep them (as soap:Envelope, xsi:type, etc.) only if you plan to round-trip the YAML back to XML via the YAML to XML converter, or if a downstream parser keys off the namespaced name. Stripping typically removes 10-20% of the output size.

Why did my XML attribute value `true` become a boolean in YAML?

YAML 1.1 parsers automatically infer types from unquoted scalars: true, yes, on, y all become boolean true; null, ~, empty values become null; 01:30 becomes the sexagesimal integer 5400. XML attributes are always strings, so the round-trip is lossy unless you enable "quote all scalars" in settings. YAML 1.2 dropped most of those implicit conversions (it's a strict JSON superset), but plenty of in-the-wild parsers still ship YAML 1.1 semantics — when in doubt, quote.

How does the converter handle repeated XML elements like `<item>...</item><item>...</item>`?

It detects sibling elements that share a tag name and collapses them into a YAML sequence. <items><item>A</item><item>B</item></items> becomes items:\n - A\n - B. A single <item> child remains a scalar value rather than a one-element list, which matches what most Python xmltodict and Java Jackson XML pipelines do by default. If you need single elements to also become arrays for schema consistency, post-process the YAML or pre-wrap singletons in your XML.

What happens to CDATA sections and entity references?

CDATA (<![CDATA[ ... ]]>) content drops into YAML as a plain string. If the content contains characters that would otherwise need YAML escaping (:, #, leading -, leading ?), the converter wraps the value in a literal block scalar (|) or folded scalar (>) to preserve it verbatim. Standard XML entity references (<, &, —) are resolved to their character values before YAML emission.

Can the converter handle large XML files like a 50 MB Spring config or SOAP log?

Up to about 10-15 MB it stays interactive. Beyond that, browser memory and the single-threaded JS event loop dominate — Chrome and Firefox will still finish but the editor freezes for a few seconds. For one-off conversions of multi-megabyte XML, that's fine. For repeated batch work, the command-line tooling (Python xmltodict + pyyaml, or yq -p xml -o yaml) is the right scale-out path; xconvert is positioned for interactive, on-demand jobs.

Is the conversion reversible — can I get my XML back?

Mostly yes, if you keep the default @-prefix attribute mapping and preserve namespace prefixes during the forward conversion. The YAML to XML converter recognizes the @-prefix convention and rebuilds elements with their attributes. What does not survive a round-trip: processing instructions (<?xml ...?>), DTD declarations, comment positioning, the order of attributes within an element, and the original XML's exact whitespace. For round-trip-critical workflows (digital signatures, canonical XML), don't convert — keep the XML.

How does this compare to running `yq -p xml -o yaml` locally?

yq (the mikefarah Go reimplementation) is the gold standard for batch XML→YAML and scripting; install it once and pipe files through. xconvert covers the interactive case: paste a SOAP response from a browser DevTools network tab, eyeball the converted YAML, copy it into a pull-request description. The two are complements rather than competitors — yq for pipelines and CI, xconvert for ad-hoc inspection. If your input is already valid YAML and you only need linting, use the dedicated validate YAML page; for XML well-formedness checks, validate XML.