How a YAML file becomes a workbook
Excel thinks in rectangles. A sheet is rows and columns, every row has the same headers, and a cell holds one value. YAML thinks in trees, where a key holds a scalar, a list, or another mapping, to any depth. The conversion is a set of rules for cutting the tree into rectangles, and the rules below are the ones this page applies.
| YAML shape | What the workbook gets | Example |
|---|---|---|
| Top-level list of mappings | One sheet named Data, one row per item, one column per key | - name: edge-fra-01 |
| Top-level mapping with list values | One sheet per list, named after the key | hosts: gives a sheet called hosts |
| Top-level scalars and plain mappings | A Summary sheet with key and value columns | exported: 2026-09-01 |
| Mapping inside a record | Flattened into dotted headers on the same row | contact.email |
| List of scalars inside a record | One cell, joined with commas, or JSON text, or a count | cdn, tls |
| List of mappings inside a record | One cell holding the JSON text of the list | [{"port":443}] |
| Top-level list of scalars | A single value column | - eu-central |
Two of those rows deserve a closer look. A list of mappings nested inside a record has no clean rectangular form. Three hosts with two ports each is either six rows with repeated host data or three rows with a text blob in the ports cell. This page picks the blob so row counts stay honest. If you need the six-row version, restructure the YAML so the inner list sits at the top level with a foreign key, the way a database table would.
The Summary sheet exists because config exports almost always carry metadata next to the records: an export date, an owner, a version. Dropping those silently loses context that someone reading the workbook a month later needs. Writing them as key and value pairs keeps them without polluting the record sheets with columns that repeat the same value on every row.
Worked example: a host inventory for toolexe.com
The sample file loaded by the button above is an inventory export. Trimmed to one host, it looks like this.
exported: 2026-09-01
owner: platform team
hosts:- name: edge-fra-01
role: edge
region: eu-central
cpu: 8
active: true
tags: [cdn, tls]contact:name: Priya Raman
email: priya@toolexe.com
certificates:- host: api.toolexe.com
issuer: Let's Encrypt
expires: 2026-10-02The plan comes out as three sheets. hosts gets the header row name, role, region, cpu, active, tags, contact.name, contact.email. certificates gets host, issuer, expires. Summary gets two rows, exported and owner. The cpu cell is a real number ready for SUM, active is an Excel boolean, and expires arrives as a date cell because the YAML parser reads an unquoted 2026-10-02 as a timestamp.
Column order and ragged records
Headers follow first appearance. The first record decides the opening columns, and any key a later record introduces is appended to the right. A record missing a key gets an empty cell in that column, not a shifted row. In the full sample, the third host has no tags key, so its tags cell is blank while the column still exists. This matters when the first record in a file happens to be the sparse one: the column order looks odd but no data is lost. Reorder in Excel, or move a fuller record to the top of the list.
Why the separator is a choice
Dots read best and match how most JSON tools spell paths, so they are the default. Pick underscores when the workbook feeds a SQL import or a pandas script, since contact_email survives as an identifier where contact.email needs quoting. Slashes suit teams who already write config paths that way in documentation. Whichever you choose, a key that already contains the separator character is written as is, so a.b under x becomes x.a.b and cannot be told apart from a nested a then b. Switch separators if that ambiguity bites.
Types Excel keeps and types it changes
- Integers and floats
- Written as numeric cells.
memory_gb: 32sums, sorts and charts. Excel keeps 15 digits of precision, so a 16-digit ID in a numeric field loses its last digit. Quote it in YAML to keep it as text. - Strings with leading zeros
- An unquoted
007is read by YAML as the number 7 before Excel ever sees it. Postal codes, account numbers and SKUs need quotes in the source file, not fixes in the spreadsheet. - Booleans
trueandfalsebecome Excel booleans and display as TRUE and FALSE. YAML 1.1 spellings such asyes,no,onandoffare read as plain strings by the parser used here, which follows the 1.2 core schema.- Dates and timestamps
- Unquoted ISO dates become date cells, so you get real date math and filtering. The value is interpreted as UTC. A date wrapped in quotes stays text, which is the right call for anything Excel should not reformat.
- Null and missing values
~,nulland an absent key all produce an empty cell. The workbook does not distinguish between them. If the difference matters downstream, write an explicit sentinel string in the YAML.- Multi-line strings
- Block scalars written with
|keep their newlines inside one cell. Excel shows them on one line until you turn on wrap text for the column. Folded scalars written with>arrive already joined into a single line.
Reading the sheet plan before you download
The right-hand pane lists every sheet with its row and column counts and the YAML key it came from. Use it as a sanity check. A plan showing only a Summary sheet with forty rows is the signature of a file whose records were nested one level too deep, usually a mapping keyed by ID rather than a list. Nothing in the file was a list, so every value became one key and value pair instead of a cell in a record grid, and the keys read like servers.web-01.cpu.
Sheet names are trimmed to 31 characters and stripped of the characters Excel rejects, which are the colon, backslash, slash, question mark, asterisk and square brackets. Two keys that collide after trimming get a numeric suffix. The plan shows the final names, so a renamed sheet is visible before the file exists.
Limits worth knowing before you paste
- Row and column ceilings. Excel stops at 1,048,576 rows and 16,384 columns per sheet. A YAML file large enough to hit those is also large enough to make this page slow, since parsing runs on the main thread. Files under a few megabytes convert in well under a second. Above that, a script using the same js-yaml and SheetJS libraries is the better route.
- Anchors are copied, not linked. A block shared across records through
&defaultsand*defaultsis expanded into each row. Merge keys are applied before any row is written. The workbook has no way to show that the values came from one source. - Custom tags stop the parse. Files using
!Ref,!!python/objector other application tags fail with an unknown tag error and the line where it appeared. Strip the tags or convert with the tool that owns them. - No formulas, styling or validation. The output is plain values with a header row and, if the option is on, column widths sized to content. Formatting is your job once the file is open.
- One sheet set per document. A file split by
---produces a fresh set of sheets for each document, suffixed with the document number. Kubernetes manifest bundles work this way, but a bundle of twenty manifests gives a twenty-sheet workbook, and the first-document option exists for exactly that case. - Nothing leaves the tab. Parsing and workbook generation happen in the browser after the page loads. An inventory file holding internal hostnames and on-call contact details is never sent anywhere, and closing the tab discards it.
When a different tool fits better
A flat list with no nesting has no need for a workbook. The YAML to CSV converter gives you a plain text file that every import wizard, database loader and version control system handles more gracefully than XLSX. If the spreadsheet is the thing you already have and the records need to become config, save it as CSV and run the CSV to SQL converter or paste the rows into the JSON to YAML converter after a JSON export. If the goal is checking the file rather than exporting it, the YAML validator lists every syntax problem at once instead of stopping at the first.
