YAML converter
Convert YAML files with care for YAML 1.1 booleans, anchors, comments, nesting, schemas, and JSON or table targets.
.yaml · .yml
Format
About YAML
YAML is a human-readable structured data format used for configuration, infrastructure definitions, documentation metadata, and hand-edited exports. It represents mappings, sequences, scalars, nulls, and nested values with indentation instead of braces. YAML can be pleasant for people, but that readability creates conversion risk: spaces are syntax, tabs are usually invalid for indentation, and a small alignment mistake can move data into a different parent object. Our tabular conversions read YAML into structured records when possible, then write JSON, JSONL, CSV, TSV, XLSX, ODS, XML, SQL, Parquet, HTML, Markdown, or TXT through the enabled pairs.
Versions matter more than many teams expect. YAML 1.1 treated values such as yes, no, on, and off as booleans in many parsers; YAML 1.2 aligned closer to JSON and reduced those surprises. Files may include anchors and aliases, merge keys, custom tags, multi-document separators, folded block scalars, literal block scalars, and comments. Comments help humans but are usually lost when converting to JSON or tables because they are not data values. Custom tags may only make sense to the original application. A converter can preserve the parsed data model, but not every authoring convenience survives.
Readers and writers include Kubernetes, GitHub Actions, Ansible, Docker Compose, static-site generators, OpenAPI tooling, package managers, and internal admin systems. Those ecosystems often expect a specific schema on top of YAML syntax. A Kubernetes manifest is not interchangeable with a content front-matter block just because both are YAML. A YAML inventory may contain anchors that reduce duplication for humans, while the expanded data is what machines receive. A data export may use YAML only because it is easier to review in version control. Identify the receiving schema before choosing JSON, XML, or a spreadsheet target.
YAML conversion breaks around typing and comments. YAML to JSON is usually safe for ordinary mappings and lists, but comments, anchors, formatting, and tag names disappear. YAML to CSV or XLSX only works cleanly when the YAML is a list of similarly shaped objects. YAML to SQL needs flat records and a table name. YAML to XML must choose how keys map to elements and attributes. Before converting, run a parser, check whether multi-document streams are present, expand anchors if needed, and keep a copy of the source when comments or ordering explain operational intent.
Common YAML problems
The word on becomes true after parsing.
Quote ambiguous scalars before /convert/yaml-to-json, especially when the receiver uses older YAML 1.1 rules.
Comments explain production settings but vanish in output.
Use /convert/yaml-to-txt for review copies, or keep YAML as the source when comments carry operational context.
Nested configuration does not fit a spreadsheet.
Use /convert/yaml-to-json for nested data, and reserve /convert/yaml-to-xlsx for lists of similarly shaped records.
An API consumer requires XML.
Use /convert/yaml-to-xml, then inspect repeated arrays because element names are inferred from YAML keys.
A tab character breaks indentation.
Replace tabs with spaces before conversion, then use /convert/yaml-to-json to confirm the parsed tree has the expected shape.