A TSV file is a text file holding a table. Each line is a row, and within a line a tab character marks the boundary between one column and the next. That is the whole format. There is no header declaration, no type system, no schema, no metadata — which is both why it has survived for forty years and why it goes wrong in the ways it does.
Open one in a text editor and you see something like this, where each gap is a single tab:
key en es
item_mug Ceramic mug Taza de cerámica
item_tee T-shirt Camiseta
Three columns, three rows, and the first row is a header only because everything reading the file has agreed that it is.
What a TSV file actually contains
Four things decide whether two programs agree about a file:
- The delimiter. A tab,
U+0009. One tab per boundary — two tabs in a row mean an empty cell between them, not extra spacing. - The line ending.
LFon Unix and macOS,CRLFon Windows. A file written on one and read on the other often gains an invisible carriage return at the end of every last column. - The encoding. Almost always UTF-8 today. If the file came out of an older Windows tool it may be windows-1252, and reading it as UTF-8 turns every accented character into a replacement glyph.
- The byte order mark. Three bytes at the very start that announce UTF-8. Most tools do not need it; Excel effectively does.
None of that is written down inside the file. Every one of the four has to be guessed by whatever opens it, which is where most corruption starts.
Where the format leaves off
The original tab-separated convention has no quoting rules at all. A cell simply cannot contain a tab or a newline, because there would be no way to tell it apart from a real boundary.
In practice, tools borrowed the quoting from CSV: wrap the value in double quotes, and double any quote already inside it.
key note
item_mug "Two sizes: small and large"
This works, and most parsers accept it, but it is a convention rather than a standard — which is worth knowing before you rely on it for a file someone else’s software has to read. When a cell genuinely needs to hold a tab, the safer answer is usually to remove the tab.
Why tabs rather than commas
Prose contains commas constantly. Mug, ceramic, large is one product name and three CSV columns unless something quotes it correctly, and plenty of things do not.
Prose almost never contains tabs. Nobody types one inside a sentence, and most input fields will not even accept one. So a TSV file usually needs no quoting at all, which means fewer rules for a parser to get wrong, files that stay readable in a plain text editor, and columns that line up on screen without help.
That is why tab-separated data is the default in bioinformatics, in game localisation exports, in log pipelines and in anything that gets processed with cut, awk or sort.
The trade-off: a tab is invisible. A CSV with a missing comma looks wrong immediately. A TSV with a missing tab looks like a slightly wide cell.
The four things that break a TSV
A spreadsheet opened it. This is the big one. Excel imports 03-04 as the fourth of March, strips the leading zero off 00891, and renders a long identifier in scientific notation. Save, and the original values are gone.
A cell picked up a stray tab. Usually pasted in from somewhere else. That one row now has one more column than every other row, and every value after the split lands in the wrong place.
Invisible whitespace. A trailing space after a key, a non-breaking space where a normal one belonged, an ideographic space in a Japanese string. All of them make a lookup fail while looking perfectly correct.
Mixed line endings. A file edited on two platforms ends up with some LF and some CRLF lines. Some parsers cope; some produce a trailing \r in the final column of half the rows.
Opening one safely
The rule is simple: do not use a spreadsheet as your TSV editor. A spreadsheet’s job is to interpret values, and interpretation is exactly what you do not want.
Use a text editor if you only need to read the file, and something column-aware if you need to change it. The editor here reads a TSV into a grid, shows every space and tab where it sits, and writes the file back with the encoding, line ending and quoting it arrived with — so the parts you did not touch are byte-for-byte what they were.
If you need the data somewhere else, converting is usually safer than re-saving: see TSV to CSV, TSV to JSON or TSV to Excel.