What is a TSV file?

TSV is a plain-text format you can open in any editor. It is used for moving data between programs.

The extension is .tsv, and the full name is Tab-Separated Values. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1993. The specification is IANA text/tab-separated-values.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

TSV stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

TSV has no comment syntax. Anything explanatory has to live outside the file, which is worth knowing before choosing it for something a human will edit by hand.

Microsoft Excel, LibreOffice Calc and pandas read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

TSV is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

The recurring complaints: column types are guessed on import rather than stated.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

A comma appears constantly inside real data — in addresses, company names, product descriptions, any free text at all. CSV handles that with quoting rules, and those rules are where the format goes wrong: a field containing a quotation mark inside a quoted field containing a comma is legal, unpleasant, and implemented inconsistently by half the tools that claim to read CSV.

A tab character almost never appears inside a field, because nobody types one into a form or a database. So TSV can usually dispense with quoting altogether: split each line on the tab and you have the fields, correctly, with no state machine and no edge cases. That is the whole argument, and on messy real-world data it is a strong one.

Bioinformatics, where genomic annotation files, expression matrices and variant tables are tab-separated as a matter of course. Command-line data work, because the standard Unix tools split on whitespace and a tab-separated file is a first-class citizen there in a way a quoted CSV is not.

Also large public datasets and database exports, where the data contains commas and prose and the exporter would rather not think about quoting. If you have been handed a .tsv or a .tab file, it came from one of those worlds.

The tab’s virtue is also its defect: you cannot see it. A file with a tab in one place and four spaces in another looks identical in an editor and parses completely differently, and a value that has picked up a trailing tab is indistinguishable from one that has not.

This bites hardest when a file is edited by hand or assembled by a script that used spaces somewhere. Any decent editor can show whitespace characters, and turning that on before touching a TSV is a two-second habit that prevents an hour of confusion. It is also why a TSV should never be built by string concatenation without checking what the fields contain.

The IANA specification is uncompromising: fields may not contain tabs or newlines, full stop. There is no escaping mechanism, which is exactly what keeps parsing simple.

In practice two conventions have grown up. Some producers escape them with backslash sequences, borrowing from C; others apply CSV-style quoting on top, which reintroduces everything TSV was avoiding. Neither is universal, so a file containing embedded tabs is a file whose reader has to match its writer. If your data genuinely contains tabs or newlines inside fields, CSV with proper quoting is the more honest choice.

Excel opens a .txt or .tsv through the import dialog and handles tabs correctly, and double-clicking a .tsv often does something less helpful depending on what is registered to the extension. It also applies exactly the same type guessing that ruins CSVs — leading zeros vanish, codes become dates, long identifiers lose precision.

So the advice is identical to the CSV case: import rather than open, set the awkward columns to Text, and if the recipient is a person rather than a program, send XLSX instead and remove the guessing entirely.

CSV when the file is going somewhere unknown. It is what upload forms, import routines and business software expect by name, and a tool that accepts only one of the two accepts CSV.

TSV when you control both ends and the data is messy — full of commas, quotation marks and free text — or when the work is happening on a command line. The parsing is simpler, the failures are fewer, and nothing has to agree about quoting rules.

Converting between them is mechanical in one direction and needs care in the other: CSV to TSV must check that no field contains a tab, and TSV to CSV must add quoting wherever a field contains a comma. A converter that skips either produces a file that looks right and has silently shifted columns.

TSV streams, which is its other quiet advantage. A file of any size can be read line by line without loading it whole, so a several-gigabyte export is workable in a way the equivalent spreadsheet is not.

For anything genuinely large and repeatedly analysed, Parquet is the better destination: columnar, compressed, typed, and dramatically faster for the queries people actually run. TSV is the right format for exchange and the wrong one for a dataset you are going to read a hundred times.