YAML to Excel Converter

Paste an inventory, a config export, or a list of records and get an XLSX workbook with one sheet per top-level list. Nested keys turn into dotted headers, top-level scalars land on a Summary sheet, and the sheet plan shows every sheet before you download a byte.

YAML to Excel workbench

YAML source0 lines
Sheet planWaiting for YAML

    0 sheets

    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.

    Where each YAML shape ends up
    YAML shapeWhat the workbook getsExample
    Top-level list of mappingsOne sheet named Data, one row per item, one column per key- name: edge-fra-01
    Top-level mapping with list valuesOne sheet per list, named after the keyhosts: gives a sheet called hosts
    Top-level scalars and plain mappingsA Summary sheet with key and value columnsexported: 2026-09-01
    Mapping inside a recordFlattened into dotted headers on the same rowcontact.email
    List of scalars inside a recordOne cell, joined with commas, or JSON text, or a countcdn, tls
    List of mappings inside a recordOne cell holding the JSON text of the list[{"port":443}]
    Top-level list of scalarsA 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-02

    The 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: 32 sums, 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 007 is 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
    true and false become Excel booleans and display as TRUE and FALSE. YAML 1.1 spellings such as yes, no, on and off are 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
    ~, null and 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

    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.

    Questions from real exports

    Nested mappings, dates that turned into numbers, and the other things people ask after opening the workbook.

    Why did my records land on the Summary sheet as key and value pairs?

    The file is a mapping keyed by ID rather than a list. YAML like servers: { web-01: {...}, web-02: {...} } is a plain mapping, so the converter writes it to the Summary sheet as key and value pairs with keys such as servers.web-01.cpu, one pair per line. Rewrite the block as a list, with each server as a - item carrying its own name key, and the plan changes to a servers sheet with a row per server.

    Is there a way to expand a nested list of objects into extra rows instead of a JSON cell?

    Not here. A list of mappings inside a record is written as JSON text in one cell, because expanding it means repeating the parent data across several rows and the row count then stops matching the record count. Move the inner list to the top level and add a key that references the parent, and each list becomes its own sheet with a clean join column.

    My dates show as numbers like 46270 in Excel. Why?

    The cell holds a real date and the column has the General number format. Excel stores dates as day counts since 1900, and 46270 is 2026-09-01 in that scheme. Select the column and apply a date format to see the calendar value. If you want the text form exactly as written in the YAML, wrap the date in quotes in the source file.

    Where did my leading zeros go?

    YAML parsed them away before the workbook was built. An unquoted 00420 is the integer 420 to any YAML 1.2 parser. The fix is in the source: write the value as "00420" with quotes, and the converter writes it as a text cell that keeps every character.

    What happens to a key that appears in only some records?

    The column is created when the key first appears and every record without the key gets a blank cell there. No row shifts and no data is dropped. The column position follows first appearance, so a key seen only in record nine sits at the far right of the sheet.

    Does the workbook keep YAML comments?

    No. Comments are discarded by the parser and never reach the sheet. If a comment carries information the spreadsheet reader needs, turn it into a real key, either on the record or at the top level so it lands on the Summary sheet.

    How large a file will this handle?

    A few megabytes of YAML converts in under a second on a laptop. Past ten megabytes the page starts to lag while typing because every keystroke re-parses the file, and the browser holds the parsed tree, the row arrays and the workbook bytes at the same time. For exports at that scale, run the same conversion in Node with js-yaml and SheetJS, which use identical rules.