CSV vs TSV: Why the Delimiter Actually Matters
By Andrew Butson · July 2, 2026 · 6 min read
The entire difference between CSV and TSV comes down to one character: CSV separates columns with a comma, TSV with a tab. That sounds trivial until your data contains commas, such as addresses, prose, or numbers written with a comma as a thousand separator, at which point CSV needs quoting rules to tell a comma-in-a-value apart from a comma-as-delimiter, and TSV mostly doesn't, because a literal tab almost never turns up inside ordinary data.
For everyday spreadsheet and database exchange, CSV wins on sheer ubiquity: it is the format every tool expects by default. Reach for TSV specifically when your values are riddled with commas, or when you are feeding data into simple line-splitting scripts and command-line tools that assume tab-delimited input, as is common in bioinformatics and database dumps.
CSV (Comma-Separated Values) has been moving tabular data between systems since the early days of mainframe computing, with its quoting conventions eventually written down formally in RFC 4180. TSV (Tab-Separated Values) does the same job with one substitution, a tab character in place of the comma, and is registered with IANA as its own media type. Structurally they are near-identical: plain text, one row per line, a header row naming the columns, no types, no formatting, no multiple sheets.
The choice between them is really a bet about what your data looks like. If a comma is unlikely to appear inside any value, CSV's near-universal tooling support makes it the obvious default. If commas are common in your values, such as names, addresses, descriptions, or numbers formatted with thousand separators, a delimiter that basically never collides with real content starts to look like the better bet.
| CSV | TSV | |
|---|---|---|
| Delimiter | Comma ( , ) | Tab ( \t ) |
| Comma-in-value handling | Needs quoting — the value is wrapped in quotes | Not an issue — commas pass straight through unquoted |
| Quoting/escaping rules | Defined by RFC 4180, but inconsistently implemented | No universal escaping mechanism for a literal tab |
| Tab-in-value handling | Not an issue — tabs pass straight through | Breaks the format — TSV assumes no field contains a tab |
| Standard | RFC 4180 (2005) | Registered IANA media type |
| Tooling ubiquity | The default export/import format almost everywhere | Widely supported, but a notch less universal than CSV |
| Excel default export | Comma — except in comma-decimal locales, see below | Not Excel's default save format |
| Typical home | Spreadsheets, databases, general data exchange | Bioinformatics, command-line pipelines, database dumps |
| Human legibility on screen | Delimiter is visible | Delimiter is invisible — looks identical to spaces |
The delimiter decision
Every argument about CSV versus TSV traces back to one design choice: which character marks the boundary between columns. A comma is a natural pick because it's common on a keyboard and reads clearly as a separator — but it's also common inside real data, which is exactly the problem. A tab, by contrast, is a character that essentially never appears inside a value someone typed by hand, which makes it a quieter, less collision-prone delimiter for the price of being invisible on screen.
Neither choice is objectively correct; each is a trade-off between how often the delimiter collides with real content and how easy the file is to read, edit and generate by eye. CSV optimises for the second at some cost to the first. TSV does the reverse.
Why commas collide with real data
Commas turn up constantly in exactly the kind of text people put in spreadsheets: a street address ('123 Main St, Apt 4'), a name written surname-first ('Smith, Jane'), free-text notes and descriptions, and, in many European locales, numbers themselves, where a comma is the decimal separator rather than a thousand separator. Any of these breaks a naive comma split, silently shifting every column after the offending value one position to the right.
TSV mostly sidesteps this because a tab character is not something people type into ordinary prose, addresses or numbers. It has its own narrower version of the same risk, genuinely tab-containing data, which does turn up occasionally in text copied from formatted sources, but it's a far rarer collision than a comma is.
CSV's complexity tax: quoting and escaping
CSV solves the comma-collision problem with quoting: a field containing a comma, a line break or a double quote is wrapped in double quotes, and any literal double quote inside it is escaped by doubling it. RFC 4180 wrote these conventions down formally in 2005, decades after CSV was already in wide informal use, which is exactly why real-world files still disagree about the details: some tools quote every field defensively, some only quote when necessary, and some get the escaping wrong entirely. The rules exist; not every CSV writer follows them precisely.
That quoting logic is CSV's complexity tax: parsing a CSV file correctly means implementing a small state machine, not just splitting on commas. TSV's classic convention avoids the tax by simply declaring that a field may not itself contain a literal tab or newline. Full stop. There's no universal escaping mechanism for it, so a naive tab-split works reliably in the overwhelming majority of cases, at the cost of having no defined fallback for the rare file where a tab does sneak into a value.
TSV's simplicity versus CSV's ubiquity
Where TSV genuinely wins is trivial parsing: split each line on the tab character and you have your columns back, no quoting logic required. That simplicity is why so many command-line tools and database export utilities default to tab-delimited output, and why TSV is the standing convention across bioinformatics, where gene tables, variant summaries and annotation files are routinely tab-delimited by long-standing field practice.
Where CSV wins is everything downstream of the file: it is the format every spreadsheet, database client, analysis library and web form expects when it says 'upload a CSV', and that ubiquity outweighs the quoting overhead for most everyday use. TSV is far from obscure: spreadsheet programs open it cleanly and it's an IANA-registered media type, but if a tool only accepts one option without asking, that option is almost always CSV.
An honest aside: Excel's regional semicolon chaos
One of the more common CSV surprises has nothing to do with commas colliding inside values, and everything to do with regional settings. In locales where the comma is used as the decimal separator, much of continental Europe for instance, Windows expects a different character to separate list items, and Excel follows that convention when it saves a 'CSV': it uses a semicolon instead of a comma. Open that file on a machine configured for a comma-decimal locale and it looks correct; open it somewhere expecting comma-separated values and every row lands in a single column. Nothing about the data is wrong: the delimiter has simply changed to avoid clashing with the decimal point, but it catches people out constantly, and it's worth knowing about before you assume a '.csv' file is always comma-delimited.
Use CSV when…
- A tool or upload form explicitly asks for CSV and nothing else.
- Your values are unlikely to contain literal commas, or your source quotes them properly.
- You need the widest possible spreadsheet and database compatibility.
- You are exporting from or importing into Excel or Google Sheets by default.
Use TSV when…
- Your data is full of commas — addresses, names, free text or European-style decimals.
- You are piping data through command-line tools that assume tab delimiting.
- You work in bioinformatics or another field where TSV is the standing convention.
- You want trivial parsing without implementing CSV's quoting rules.
Frequently asked questions
- Is TSV better than CSV?
- Neither is strictly better. TSV wins when your data is full of commas, because it avoids quoting entirely; CSV is more forgiving when fields might contain tabs or need arbitrary escaping, since it has a defined quoting scheme that TSV lacks. Pick based on which delimiter is least likely to appear in your actual values.
- Can I open a TSV file in Excel or Google Sheets?
- Yes. Most spreadsheet programs recognise the tab delimiter automatically on import, though some ask you to confirm the separator: if columns land in a single cell, tell the importer to split on tabs rather than commas.
- Why did my CSV file open as one column on a European colleague's computer?
- Most likely because it was exported by Excel on a machine set to a comma-decimal locale, where Excel uses semicolons instead of commas to separate CSV fields. The file is not corrupted: it's semicolon-delimited, so importing it with the correct separator selected fixes the display immediately.
- Does TSV have a quoting rule for values that contain tabs?
- Not a universal one. The classic TSV convention simply assumes no field contains a literal tab or newline; if your source data genuinely does, either sanitise it before export or use a stricter, escaping-aware variant rather than plain TSV.