TSV vs CSV: Tab-Separated vs Comma-Separated Values

A TSV file is a plain-text table where columns are separated by tab characters instead of commas. That is the whole difference from CSV: TSV uses a tab (the invisible character you get from the Tab key) as its delimiter, while CSV uses a comma. Both store rows of data as lines of text, and both open in Excel, Google Sheets, and any code editor. The choice comes down to what your data contains.

What a TSV file is (tab-separated values)

TSV stands for tab-separated values. Each line is a row, and inside each line a single tab character marks the boundary between one field and the next. A file with three columns and two rows looks like this:

name	city	role
Ana	Bengkulu	editor
Budi	Jakarta	writer

The gaps you see above are real tab characters, not runs of spaces. That distinction matters: a tab is one specific byte (0x09), so a parser can split on it with zero ambiguity. The .tsv extension is the common one, though you will also see .tab and plain .txt used for the same thing.

TSV has been around a long time. The US Library of Congress documents it as a recognized format, and it is the default clipboard format when you copy cells out of a spreadsheet. Paste a range from Excel into a text editor and you get tab-separated values, whether you asked for them or not.

TSV vs CSV: the delimiter and why it matters

The delimiter is the character that says “new field starts here.” CSV picks the comma. TSV picks the tab. Everything else about the two formats is nearly identical, so csv vs tsv really is a question about that one character.

Here is why the choice is not cosmetic. Commas show up inside real data constantly: prices (“1,500”), addresses (“Seginim, Bengkulu Selatan”), and any sentence with a list. When a value contains the delimiter, a plain parser splits in the wrong place and your columns shift. CSV solves this by wrapping such values in quotes, which adds its own rules (more on that below).

Tabs almost never appear inside normal field values. People do not type tabs into a name or a city. So tab separated values sidestep the biggest source of CSV breakage: you rarely need quoting at all, because the delimiter and the content do not collide.

Where TSV wins: data full of commas and quotes

Reach for TSV when your fields are messy with punctuation. Free-text columns, product descriptions, addresses, anything a human typed. If half your values contain commas, a CSV of that data is a wall of quotes and escaped quotes, and one missing quote corrupts every row after it. The same data as TSV stays flat and readable.

TSV also wins for copy-paste work. Because spreadsheets already put tabs on the clipboard, TSV is the format your data is in when it leaves Excel or Sheets. Save it straight to a .tsv and there is nothing to convert.

It is friendlier to Unix tools too. Commands like cut -f2 and awk -F'\t' expect a clean single-character delimiter, and tabs give them one without the quoting logic that trips up cut on real CSV. For quick command-line slicing, TSV is less work.

Where CSV wins: tooling, support, and ubiquity

CSV wins on reach. When someone hands you a data export, it is a CSV far more often than a TSV. Government portals, bank statements, e-commerce dashboards, and almost every “Download as spreadsheet” button produce comma-separated values by default. If you want a file that any recipient can open without a second thought, CSV is the safe pick.

The tooling is deeper. RFC 4180 gives CSV a written specification for quoting and escaping, and most libraries (Python’s csv, the JavaScript ecosystem, R, every database import wizard) treat CSV as the primary target with TSV as an afterthought. You will hit fewer edge cases in someone else’s parser with a CSV.

CSV is also visible. A tab and four spaces look the same on screen, so a broken TSV is hard to eyeball, while a stray comma in a CSV is right there in the text. When you need a human to spot-check the raw file, commas are easier to see. This is the real tsv vs csv trade: TSV is cleaner to parse, CSV is more widely understood.

How each format handles escaping and edge cases

CSV’s escaping rule is the part people get wrong. If a value contains a comma, a double quote, or a line break, you wrap the whole value in double quotes. A literal double quote inside gets doubled. So the value He said "hi", loudly becomes:

"He said ""hi"", loudly"

Miss one of those quotes and the parser reads the rest of the file as a single giant field. This is the number one cause of “my import has the wrong number of columns.”

TSV takes a blunter approach. The convention (used by the IANA text/tab-separated-values type) is that fields simply cannot contain raw tabs or newlines. There is no quoting mechanism at all. If a value has a tab in it, you replace it with the literal escape sequence \t before writing, and the reader swaps it back. Fewer rules, but they depend on your data being tab-free, which it usually is.

Two edge cases bite both formats. Trailing whitespace inside a field is easy to lose, and empty final columns can vanish if a tool trims line ends. And both formats need a stated character encoding: save as UTF-8 or an accented name like “José” or an Indonesian “Yogyakarta” comes back garbled. Always confirm UTF-8 on both write and read.

Converting between TSV and CSV without breaking rows

Converting sounds trivial: swap tabs for commas, or the reverse. It is not, and the naive find-and-replace is exactly how rows break. If you replace every comma with a tab in a CSV that has quoted values, you will split fields that were meant to stay whole, and you lose the row structure the quotes were protecting.

Do it the right way. Parse the source with a real CSV or TSV reader that understands quoting, then re-serialize into the target format. Any reader that respects RFC 4180 will strip the quotes correctly on the way in and re-add them (or drop them, for TSV) on the way out. That round-trip is what keeps your row and column counts identical. If you want the mechanics of the separator itself, we cover them in csv delimiter explained, and the fuller picture of the format lives in what is a csv file.

For a one-off conversion, you do not need to write code. A spreadsheet round-trip works: open the file, then “Save As” with the delimiter you want. And if the source is a different structure entirely, comparing csv vs json will tell you whether a flat delimiter format is even the right target.

Turning either into a clean Markdown table

Often the real goal is not another data file but a readable table for docs, a README, or a blog post. Both TSV and CSV drop straight into a Markdown table, since the pipe-delimited Markdown grid is just another delimited format with borders.

You can paste a CSV or TSV into our CSV to Markdown converter and get a formatted table back, with the delimiter detected for you and the quoting handled so no row splits in the wrong place. Handy when you are copying a spreadsheet range into documentation and want the pipes lined up without hand-editing every row.

FAQ

Is a TSV file the same as a spreadsheet? No. A TSV is plain text with tab-separated columns. A spreadsheet file (.xlsx) is a compressed binary that also stores formatting, formulas, and multiple sheets. A spreadsheet can open and export TSV, but the TSV itself holds only raw values.

Can Excel open a TSV file? Yes. Excel and Google Sheets both read .tsv directly, and copying cells out of either puts tab-separated values on your clipboard. If Excel dumps everything into one column, rename the file to .txt first so it runs the import wizard where you can pick the tab delimiter.

Why use TSV instead of CSV? Use TSV when your data is full of commas, like addresses or free-text descriptions. Tabs rarely appear inside real values, so you skip the quoting and escaping that makes commas fragile. It is also the native clipboard format from spreadsheets, so there is nothing to convert.

Which is better, CSV or TSV? Neither is better everywhere. CSV wins on ubiquity and tool support, so it is the safe default for sharing. TSV wins when values contain commas or when you slice files with Unix tools like cut and awk. Match the format to your data and your audience.