How to Convert YAML to CSV: List of Objects to a Clean Table

YAML is great for humans writing config and seed data. It is terrible for anyone who wants to sort, filter, or pivot that data. The moment a product manager asks "can I see all the feature flags in a spreadsheet?", you need a table — rows and columns — not a nested indentation tree. That is exactly the gap a YAML to CSV conversion closes: a YAML list of objects maps cleanly onto a CSV table, where each list item becomes one row and each key becomes one column.

This guide walks through how that mapping works, what happens when records have different fields, how nested values get handled, and the small details that decide whether your file opens correctly in Excel.

The core idea: list items become rows, keys become columns

A CSV table has exactly two structural pieces — a header row of column names, and data rows underneath. A YAML sequence of mappings has the same shape if you look at it right: the sequence is the set of rows, and the keys of those mappings are the columns.

So the conversion is mechanical:

• Each item in the YAML list becomes one row.
• The header is the union of every key across all objects, in the order each key first appears.
• A record that is missing a key gets an empty cell in that column, not a shifted value.

That last rule matters more than it sounds. If you naively took the keys of the first object as your header, any record with an extra field would either lose data or push values into the wrong column. Taking the union of all keys keeps every column aligned no matter how ragged the input is.

If you paste a single top-level object instead of a list, it is treated as a one-row table. A list of plain scalars (no keys) collapses into a single value column. Both are sensible defaults, but the common case — and the one this whole workflow is built around — is a list of objects.

A worked example

Here is a small YAML list of three people. Notice that Bob has no age and Carol has a city the others don't:

- name: Alice
  age: 30
  city: Portland, OR
- name: Bob
  city: Seattle
- name: Carol
  age: 41
  city: Austin
  role: admin

Run this through the YAML to CSV Converter and you get:

name,age,city,role
Alice,30,"Portland, OR",
Bob,,Seattle,
Carol,41,Austin,admin

Two things to call out. First, the header is name,age,city,role — the union of every key, in first-seen order — and Bob's missing age shows up as an empty cell (Bob,,Seattle,) rather than knocking Seattle into the age column. The role column exists only because Carol used it, and the other two rows get an empty cell there.

Second, Portland, OR is wrapped in double quotes. That comma inside the value would otherwise look like a column break and scramble the entire row. The converter follows RFC 4180: any field containing the delimiter, a double quote, a carriage return, or a line break is wrapped in quotes, and embedded quotes are doubled. So he said "hi" becomes "he said ""hi""" and lands in exactly one cell. This is the difference between a CSV that opens cleanly and one that turns into garbage on the first value with punctuation in it.

Flattening nested fields

Real data is rarely flat. You will hit objects and arrays nested inside your rows — an address block, a list of tags, a metadata map. A table has no native way to hold a nested structure, so you have to decide how to project it down to columns. There are two reasonable answers, and the tool gives you both.

JSON-in-a-cell (the default). A nested object or array is stringified into a single cell. tags: [x, y] becomes the cell ["x","y"], kept whole. This is the right choice when you want to round-trip the data back to structured form later — the cell is valid JSON, so nothing is lost.

Flatten nested (a toggle). Instead of one opaque cell, the converter spreads nested values into extra columns using dotted and indexed paths:

- name: Alice
  addr:
    city: Portland
    zip: "97201"
  tags: [admin, beta]

With flattening on, that single record produces columns name, addr.city, addr.zip, tags[0], tags[1]. Now addr.city is a real column you can filter on, sort by, or feed into a pivot table. JSON-in-a-cell can't do any of that. The rule of thumb: flatten when you intend to analyze the data in a spreadsheet, keep JSON when you intend to round-trip it back to structured data.

Picking the right delimiter and encoding

The first time I converted a YAML inventory and handed the CSV to a colleague in Germany, every row landed in a single column on her screen. Nothing was wrong with the file — her Excel locale uses the comma as a decimal separator, so a comma-delimited CSV has no field breaks it recognizes. Switching the delimiter to semicolon fixed it instantly. That five-minute confusion is the single most common CSV trap, so the converter lets you choose comma, semicolon, or tab up front.

Two practical defaults worth internalizing:

• Semicolon for European Excel. If commas are decimal separators in your locale, pick semicolon (or import via Data → From Text/CSV and tell Excel the delimiter explicitly).
• Tab for clean re-parsing. A tab-delimited file (effectively TSV) almost never collides with the data, which makes it the safest pick when you'll re-import the file programmatically.

The output is UTF-8. If Chinese or accented characters show up as mojibake, don't double-click the file — use Excel's Data → From Text/CSV importer and set the encoding to UTF-8. Numbers, LibreOffice, and Google Sheets handle UTF-8 without the ceremony.

Where this fits in a real workflow

A few jobs this conversion quietly unblocks:

• Config editing by non-engineers. Feature flags or replica counts live in YAML, but the person who owns the values only speaks spreadsheet. Convert to CSV, let them edit in a shared sheet, then run the reverse with the CSV to YAML Converter to fold the changes back in. Nobody has to learn indentation rules to change a number.
• Analysis you can't do in YAML. A scraper, a CI export, or an Ansible inventory hands you a few hundred YAML objects. Convert to CSV, open in Excel, and you have sorting, filtering, and pivots for free.
• Feeding CSV-only importers. CRMs, mailing lists, and billing systems often accept CSV and nothing else. Convert, pick the delimiter the importer wants, flatten nested fields, and upload — no glue script needed.

If you only need the structured form rather than a table, the YAML to JSON Converter covers that path instead. But when the destination is a spreadsheet, CSV is the format that gets you there, and the list-to-rows, keys-to-columns mapping is what makes it reliable.

Everything runs in your browser — the parse, the column union, and the RFC 4180 writer are plain JavaScript with no upload. The one caveat: a share link encodes your YAML in the URL, so for confidential data, send the downloaded file instead of the link.

---

Made by Toolora · Updated 2026-06-13