Both formats are plain text tables. One separates columns with a comma, the other with a tab. Everything that follows comes from that single difference.
The short answer
Use TSV when the data is text written by humans — names, descriptions, translations, log messages. Prose is full of commas and almost free of tabs, so a TSV usually needs no escaping at all.
Use CSV when something downstream demands it, which is often. It is the format every tool accepts without being asked, and if you are handing a file to an unknown recipient it is the safer default.
Everything below is why.
Quoting: the real difference
CSV has a specification for this, RFC 4180, and it exists because commas appear in data constantly:
key,name
item_mug,"Mug, ceramic"
item_tee,"He said ""fits well"""
Every reader and writer has to implement wrapping, doubling and unwrapping correctly. Most do. The ones that do not produce files where a single product name has quietly become two columns — and because the row still parses, nothing raises an error.
The equivalent TSV needs no quoting whatsoever:
key name
item_mug Mug, ceramic
item_tee He said "fits well"
Fewer rules is fewer things to get wrong. That is the entire case for tabs.
Where TSV is weaker
Tabs are invisible. You cannot see whether a gap is one tab, two tabs, or a run of spaces someone typed by hand. A missing comma in a CSV is obvious on sight; a missing tab is not.
Some tools eat them. Paste a tab-separated block into a chat client, a web form or a rich text field and the tabs may arrive as spaces, or as nothing. Commas always survive.
The convention is not a standard. CSV has an RFC. Tab-separated files have a widely shared habit. Almost every parser accepts CSV-style quoting inside a TSV, but nothing guarantees it.
Where CSV is weaker
The delimiter is not always a comma. In locales that write decimals as 1,5 — most of Europe — Excel exports CSV with semicolons instead, and calls it CSV anyway. A file that opens perfectly on one colleague’s machine arrives as a single column on another’s. Tabs have no such regional variant.
Escaping is where the bugs live. Nearly every “the file is corrupted” report in a CSV pipeline traces back to a quote that was not doubled, or a quoted field containing a newline that a naive split('\n') cut in half.
It invites a spreadsheet. A .csv file has a spreadsheet icon on most systems, and double-clicking it is the fastest way to convert your identifiers into dates.
What they share, and it matters more
Neither format records its own encoding, its own line ending or whether it has a header row. Both are guessed by whatever opens the file. So both suffer identically from:
- Excel’s import guesswork —
03-04becoming a date, leading zeros vanishing, long numbers going scientific. - Encoding mismatches — a UTF-8 file read as windows-1252, or the reverse.
- Mixed line endings — some rows ending
LF, othersCRLF.
Choosing between tabs and commas does nothing about any of these. Not opening the file in a spreadsheet does.
Choosing, in practice
| Situation | Format |
|---|---|
| Free text, descriptions, translations | TSV |
| Handing a file to an unknown tool or person | CSV |
Data going through cut, awk, sort |
TSV |
| Data with commas but no tabs | TSV |
A recipient who only accepts .csv |
CSV, quoted properly |
| European colleagues opening it in Excel | CSV with semicolons, or just send XLSX |
Converting between them
The conversion is one character, but the escaping is not. Going from tabs to commas means every cell containing a comma or a quote now has to be wrapped; going the other way means unwrapping correctly, including quoted fields that span two lines.
Both directions run in the browser here — TSV to CSV and CSV to TSV — with the quoting, line ending and byte order mark set explicitly rather than guessed. And if the real destination is a spreadsheet, export to Excel directly and skip the import guess altogether.