TSV to CSV Converter

The conversion that goes wrong most often when it is guessed. The tab is pinned on the way in, and every field that now contains a comma is quoted on the way out.

To convert TSV to CSV, paste your tab-separated text or drop the file above. The tab is used as the separator without sniffing, so a file full of commas still splits correctly, and on the way out every field containing a comma, a quote or a newline is quoted so no column shifts. Choose a different output separator if you need one.

Want to clean it up while you are here? Open the app

Why this simple conversion is the one that breaks

Going from tabs to commas sounds like a find and replace, and that is exactly the implementation that ruins the file. A value containing a comma, which in a tab-separated file needed no protection at all, suddenly becomes two fields and every column after it shifts by one for that row only.

The damage is quiet. The file still opens, the header is fine, and the rows that happened to contain no commas are correct. It is the address column and the notes column that break, and they break on the specific rows somebody cares about.

Doing it properly means parsing the TSV into fields and then serialising to CSV with quoting decided against the comma. That is what happens here, and it is the reason there is a page for it.

Tab-separated, declared rather than guessed

Most converters sniff the delimiter by counting candidates in the first few lines. That works until it does not, and when it fails it fails completely: a tab-separated export whose first rows hold several commas each gets read as a CSV, and every row comes back as one column of text with tabs inside it.

Because this page declares tab-separated input, the separator is pinned rather than sniffed. A file full of commas, semicolons and pipes still splits on tabs, which is what the file says it is.

That is the whole argument for having a TSV page distinct from the CSV one. Everything else about the two is the same; the difference is that this one cannot guess wrong.

Worked example

A tab-separated export with commas in the data, tabs shown as gaps:

store_code    store_name          city              revenue
0041          Harbour Road        Osaka, Japan      1840.50
0058          Lakeside, Retail    Berlin            975.00

And the CSV:

store_code,store_name,city,revenue
0041,Harbour Road,"Osaka, Japan",1840.50
0058,"Lakeside, Retail",Berlin,975.00

Exactly two fields gained quotes, and both of them needed to. Everything else is bare, which keeps the file readable. A find and replace would have produced a file where row one has five fields and row two has five fields but the wrong ones.

Quoting, decided against the separator you chose

A field is quoted when it contains the output separator, a double quote or a newline, and not otherwise. That is the minimal correct rule and it produces the most readable file.

Choose a different output separator and the rule follows it. Pick semicolon and a field containing a comma is written plainly, because a comma means nothing in a semicolon-separated file. That sounds obvious and it is exactly what a competing converter gets wrong: asked for tab output, it still quotes values containing commas.

Quote every field is there for the cases where something downstream is strict or naive, and it is off by default because a fully quoted file is harder to read and a third larger.

What else the conversion tells you

Padded rows. A short row is padded to the header width and counted, so you know if the source was ragged rather than finding out later.
Blank rows dropped, with a count. Exports frequently end with empty lines and silently removing them changes the row count.
Duplicate headers renamed, so a second column called total becomes total_2 rather than colliding.
Blank headers named by position, so a column with no name still survives into the output.
One trailing newline, always. A file whose last line has no terminator makes wc -l undercount and can lose the final row in some tools.

Frequently Asked Questions

Why not just replace tabs with commas?

Because a value containing a comma needed no protection in the tab-separated file and needs quoting in the CSV. A find and replace turns it into two fields and shifts every column after it on that row only, which is quiet and damaging.

My file has more commas than tabs. Will it still read correctly?

Yes. This page declares tab-separated input, so the separator is pinned rather than sniffed. A heuristic counting candidates in the first few lines is exactly what fails on a file like yours.

Can I output something other than a comma?

Yes: comma, semicolon, tab or pipe. The quoting rule follows the separator you choose, so picking semicolon means a value containing a comma is written plainly rather than being needlessly quoted.

Can I force every field to be quoted?

Yes, one switch. It is off by default because a fully quoted file is harder to read and about a third larger, but some strict or naive consumers want it and it costs nothing to turn on.

What happens to short rows?

They are padded to the header width and counted, with a note saying how many. Exports are ragged more often than people expect, and finding out at conversion time is much better than finding out from a broken query later.

Can I paste straight from a spreadsheet?

Yes. Copying cells from Excel, Numbers or Google Sheets puts tab-separated text on the clipboard, so pasting into the box here works with no file involved at all.

Convert it without shifting a column

Tab pinned on the way in, correct quoting on the way out, every change reported.

Back to the converter