Why this is not find-and-replace
Swapping every comma for a tab works right up until a field contains
a comma. A row reading
"Smith, John",Leeds has two fields; replacing the
commas turns it into three, and every row after that point is
shifted by one column. The file still opens, the header still looks
correct, and the damage is invisible until someone notices a city in
the postcode column.
This uses a real parser instead. Quotes open and close, a doubled quote inside a quoted field is a literal quote, and a newline inside quotes is part of the value rather than the end of the row. Those three rules are what separate a converter from a search and replace.
When you actually want TSV
The usual reason is pasting. Copy tab-separated text and paste it into Excel, Google Sheets or Numbers and it lands in cells immediately — no import dialog, no delimiter question, no guessing at encodings. Paste CSV into the same place and you get one column of text that you then have to split.
The second reason is scripts. Command-line tools like
cut, awk and sort are
tab-oriented by default and have no idea what a quoted comma is, so
handing them a real CSV is asking for exactly the column-shift
problem described above. Converting first, once, with a parser that
understands quoting, avoids it.
The delimiter is detected, not assumed
Not every "CSV" uses commas. European versions of Excel export with
semicolons, database dumps often use pipes, and plenty of files that
end in .csv are tab-separated. The delimiter is worked
out from your data by looking at which candidate appears the same
number of times on every line — consistency, not raw frequency,
because prose contains plenty of commas but not in a regular pattern.
Characters inside quoted fields do not vote, so a file full of
"a,b,c" values separated by tabs is correctly read as
tab-separated.
A worked example
Take this three-column CSV row, where the first field is a name containing a comma and the third is a quote written by re-quoting it as two double quotes in a row:
name,role,note
"Smith, John",Editor,"He said ""hello"""
Ada Lovelace,Engineer,First programmer
The parser reads that as two rows of three fields each:
Smith, John / Editor /
He said "hello", and Ada Lovelace /
Engineer / First programmer. Converted to
TSV, with a real tab character between each field (shown here as
[TAB] because a tab is invisible on a page), it becomes:
name[TAB]role[TAB]note
Smith, John[TAB]Editor[TAB]He said "hello"
Ada Lovelace[TAB]Engineer[TAB]First programmer
Two things happened. The comma inside Smith, John
survived as ordinary text, because it was never a delimiter to begin
with — it was one character inside a field. And the doubled quotes
that meant "one literal quote" in CSV collapsed to a single
", because TSV has no need to escape a quote that isn't
doing anything special. Converting that same TSV row back to CSV
re-adds the quoting: the note field would be wrapped in quotes again
and its internal quote doubled, because it's the comma-free tab
format that can afford to treat quotes as plain characters, not CSV.
The one thing TSV cannot do
TSV has no quoting convention that software agrees on. That means a value containing a tab or a newline genuinely cannot be represented, and there is no clever encoding that every reader will understand.
So going to TSV those characters are replaced with spaces, and the count is reported under the output — "3 values had tabs or newlines replaced with spaces". The alternative is a file that silently gains a column, which is exactly the failure this tool exists to prevent. Going the other way, to CSV, nothing is lost: quoting handles it.
Excel's byte-order mark
Excel writes an invisible marker at the start of the files it saves.
Left in place it becomes part of your first column's name, so a
header that looks like id is really something else and
every lookup against it fails for reasons nothing on screen
explains. It is consumed here rather than treated as data.
Empty rows, padding and quoting
Three options change how the output looks without changing what the parser reads. "Remove completely empty rows", on by default, drops any row where every field is blank — the kind a trailing blank line in the source file produces. "Pad short rows" fills every row out to the width of the widest one, so a file where some rows have fewer columns than others still lines up. "Quote every field" — CSV output only, since TSV never quotes — wraps every field in quotes rather than only the ones that contain a comma, a quote or a newline; some tools that read CSV expect that and get confused without it.
Line endings are a separate choice from any of that: CRLF (a carriage return followed by a line feed) is what Windows and Excel write and expect, LF (just a line feed) is what everything else uses. Either is accepted on the way in, whichever one you pick controls the way out.
Common mistakes this avoids
The most common one is treating CSV as "comma-separated" literally
and splitting text on every comma, which is exactly the bug described
above. A close second is assuming every "CSV" file uses commas at
all — plenty use semicolons or tabs and still carry a
.csv extension, which is why the delimiter here is
detected rather than assumed. A third is opening the result in a
plain text editor and being unable to tell it worked, because tab
characters render as a few spaces that look identical to a mistake;
the row and column counts under the output are there to check
against instead of eyeballing whitespace.
When to use a different tool
This page is for going between CSV and TSV specifically. Converting the same rows into plain lines of readable text instead of another delimited format is a different job, handled by CSV to TXT. Turning a row per contact into individual address-book entries is different again — see CSV to vCard if that's the actual goal rather than a delimiter swap.
Limits and privacy
Everything runs in your browser: the parser, the writer and the file reader. This page has no upload endpoint, so a file you drop is read on your own device and its text goes straight into the box. Nothing is logged and there is no account.
A dropped file is capped at ten megabytes and the parser at roughly two million cells. Past that, a browser tab is the wrong tool — a spreadsheet or a short script will be faster and will not have to hold the whole thing in memory at once.