Convert CSV to a YAML sequence of mappings — header row as keys, values typed by the same inference rules as the CSV to JSON converter, leading-zero identifiers kept as quoted strings, and duplicate headers reported instead of silently overwriting a column. Free, no sign-up — runs locally in your browser.
Why convert CSV to YAML?
CSV is the format data escapes spreadsheets in; YAML is the
format configuration and data pipelines run on. The trip
between them happens constantly: a product list maintained in
Sheets becomes the data file for a static site, an exported
report becomes test fixtures, a spreadsheet of settings becomes
an Ansible or CI variable file. Doing it by hand means
re-typing rows into mappings and hand-quoting every value YAML
might misread — which is most of the interesting ones. This
converter does the mechanical part: header row to keys, rows to
a sequence of mappings, values typed and quoted by the same
rules as the CSV to JSON converter here, so the two tools never
disagree about what your data means.
How to use this tool
- Paste the CSV, upload a file, or drop one on the panel. The first row must be the header row.
- Pick the delimiter if your file is not comma-separated, and decide on type inference — leave it on for data, off for identifier-heavy files.
- Press Convert to YAML. The status line reports the data-row and column counts it found.
- Copy or download the result. Structural problems — duplicate headers, a row wider than the header, an unterminated quote — are errors with positions, never silent repairs.
The mapping rules
Header row → keys. Row 1 names the columns;
every later row becomes one mapping in a top-level sequence, in
file order. Duplicate headers abort the conversion by name;
empty header cells are named columnN by position.
Cells → scalars. With inference on, integers,
decimals, true/false and the literal
null become typed YAML scalars; a number-spelled
cell with a leading zero (007) stays a string,
because the zero is part of the value. Strings that YAML would
read as something else (yes, on,
~, anything containing : ) are
quoted by the emitter. Shape problems. Short
rows are padded with empty strings; long rows are an error.
Quoted fields follow RFC 4180, including delimiters and
newlines inside quotes.
Worked example
This CSV:
name,role,active,code
Ada Lovelace,engineer,true,007
Grace Hopper,admiral,false,042
converts, with inference on, to:
- name: Ada Lovelace
role: engineer
active: true
code: "007"
- name: Grace Hopper
role: admiral
active: false
code: "042"
The booleans became booleans; the codes stayed strings with
their zeros — and the quotes are YAML being told, explicitly,
not to second-guess that.
Frequently asked questions
Which row becomes the keys?
The first row — always. CSV has no way to declare 'this is a header', so the converter follows the near-universal convention that row 1 names the columns and every row after it is data. If your file has no header row, the first data row will be consumed as keys; add a header row first (or convert with the CSV tools here to inspect the file) — the converter cannot guess, because a headerless file and a headered one are indistinguishable from the bytes alone.
Why did my ID 007 come out as "007" with quotes?
Because that is the only safe way to write it in YAML. Inference is on: the cell looks at the value and asks what it means. 007 as a number would just be 7 — the zeros carry information (it is an identifier, not a quantity), so the converter keeps it a string, and YAML needs the quotes because an unquoted 007 in YAML 1.1 reads as an octal-ish number to some parsers. The same protective quoting applies to cells like yes, no, on, null and ~, which YAML would otherwise read as booleans or nulls.
What types does inference produce?
The same set as this site's CSV to JSON converter, so the two tools agree about your data: integers, decimals, true/false booleans and the literal null become real YAML scalars; empty cells become empty strings; everything else stays a string. Turn inference off and every cell is a string, quoted wherever YAML would misread it — the right choice when the file is all identifiers and codes.
What happens with duplicate or missing headers?
Duplicate headers are an error, reported by name: two columns called the same thing would overwrite each other in every row's mapping, silently losing one column of data. An empty header cell is the recoverable case — it is named column1, column2, … by position and the conversion proceeds. A data row with too many fields is an error (there is no key to put them under); a row with too few is padded with empty strings, matching how spreadsheet exports behave.
My CSV uses semicolons / tabs. Does it still work?
Yes — pick the delimiter above the Convert button. A large share of European spreadsheet exports use semicolons because the locale's decimal separator is a comma, and tab-separated exports are common from databases. The delimiter applies to the whole file; mixed delimiters in one file are not a thing any CSV parser can untangle, including this one.
How is the output shaped — a list of mappings, always?
Always: a YAML sequence whose items are mappings, in file order, keys in header order. That is the shape YAML consumers expect for row data (it round-trips through yq, Python's yaml and every config loader), and it preserves duplicates and ordering that a mapping-of-mappings would destroy. If you need the rows keyed by one column instead, that is a reshaping step — convert to JSON with the tools here and restructure there, where the operation is explicit.
Dev