YAML to Excel Converter
Review a config the way it was decided. Forty indented blocks become forty rows you can sort, filter and compare side by side.
To convert YAML to Excel, paste your file or drop it above. A sequence of mappings becomes rows, nested mappings flatten into dotted columns, and each column is written with one cell type. Several documents separated by three dashes each become a row. The workbook has a frozen header, fitted widths and real number, boolean and date cells.
Want to compare two environments? Open the app
The direction people forget to ask for
Everyone converts spreadsheets into config. The reverse is just as common and much less discussed: the config already exists, it has grown to forty services across three environments, and nobody can see it any more.
A spreadsheet answers the questions a YAML file cannot. Which services have autoscaling off in production. Which cost centre appears twice. Whether staging and production actually differ where you think they do. Those are a sort and a filter, and they are impossible to eyeball in eight hundred lines of indentation.
The other reason is review by people who do not read YAML. A finance lead checking cost centres or a compliance reviewer checking retention periods wants a table.
Worked example
A deployment matrix:
- service: billing-api
environment: production
replicas: 6
log_level: info
autoscale: true
cost_centre: "01730"
released: 2026-01-08
- service: web-frontend
environment: production
replicas: 4
log_level: warn
autoscale: true
cost_centre: "02139"
released: 2026-01-12And what lands in the workbook:
- service, environment, log_level text.
- replicas numeric cells that sum and sort.
- autoscale real boolean cells showing TRUE and FALSE, which COUNTIF can count.
- cost_centre text, keeping
01730intact, because the YAML quoted it and this respects that. - released real date cells formatted
yyyy-mm-dd.
Two rows, seven columns, and a frozen header. Add a third environment to the file and the workbook grows a row rather than eleven lines you have to read carefully.
The YAML shapes it reads
- A sequence of mappings is the ordinary case: one entry, one row.
- Several documents separated by
---become one row each when they are all mappings, which is the Kubernetes manifest shape and the useful reading of it. - A single mapping becomes a one-row table.
- Nested mappings flatten into dotted columns, so
resources.limits.cpuis one column. - A sequence of scalars becomes a single column called value, rather than an error.
- Anchors, aliases and merge keys are resolved by the parser before the table is built, so a manifest that reuses a block through
<<: *defaultscomes out with the merged values in place.
What YAML has already done to your values
By the time a reader sees a YAML file, the parser has resolved bare words into types. An unquoted 2026-01-08 is a date object, an unquoted no is the boolean false, and an unquoted 01730 is the number 1730 with its zero gone.
That happens inside the YAML parser, before anything here can intervene, which is why the quoting in the source file matters so much. A cost centre written with quotes arrives as the string it is. The same value written without them arrived as a number and the zero was lost by the file's own author, not by the conversion.
This is worth knowing because it makes the round trip asymmetric. Our CSV to YAML and Excel to YAML pages quote everything a reader might coerce, precisely so that converting back gives you the same values. A file written by something less careful may not.
Multi-document files and Kubernetes
A file of manifests separated by --- is the most common multi-document YAML anybody has. When every document is a mapping, each one becomes a row, which turns a directory of manifests into a table of workloads with their images, replica counts and namespaces side by side.
The flattening is what makes that readable. A manifest's nested spec becomes columns like spec.replicas and spec.template.spec.containers, and nesting past four levels is kept as text in one cell so the header row does not run to two hundred columns.
A note under the result says how many documents were combined, so you always know whether you are looking at one manifest or twelve.
Frequently Asked Questions
Does it handle a file with several documents separated by three dashes?
Yes. When every document is a mapping, each becomes a row, which is the useful reading of a Kubernetes manifest file. A note under the result says how many documents were combined so you always know what you are looking at.
Are anchors and merge keys resolved?
Yes, by the parser, before the table is built. A file that defines a defaults block and merges it into six entries produces six complete rows rather than six rows with holes and one row of defaults.
Why did a cost centre lose its leading zero?
Because the YAML file did not quote it. An unquoted 01730 is the number 1730 to any YAML parser, and the zero was gone before this tool saw the file. A quoted value arrives intact, which is why our own YAML writers quote anything a reader might coerce.
How is nesting handled?
Nested mappings flatten into dotted columns, so resources.limits.cpu becomes one column. Nesting past four levels is kept as text in a single cell, because a spreadsheet header of six-part names is not something anyone can read.
What happens to a list inside an entry?
It is kept as text in one cell rather than being spread across extra rows. Spreading it would change the row count, and a workbook that has more rows than the config has entries is one whose counts cannot be trusted.
Is the file uploaded?
No. Parsing and workbook building both happen in your browser tab. That matters here because config files routinely carry hostnames, account identifiers and occasionally something that should not have been committed.
See the config as a table
Typed cells, flattened nesting, one row per entry. Sort it and find the odd one out.
Back to the converter