TSV to CSV: How to Convert Tab Delimited Data Without Breaking Your Columns

Tab-separated values and comma-separated values look almost identical when you open them in a text editor. Both are plain text, both have one row per line, and both split a row into fields. The only difference is the character between fields: TSV uses a tab, CSV uses a comma. That single character is also why a naive find-and-replace breaks things the moment a real cell contains a comma of its own.

This post walks through what actually has to happen when you convert TSV to CSV, why the comma is trickier than it looks, and how to do the conversion cleanly when the data comes out of a database, a spreadsheet, or a script.

Why People End Up With TSV in the First Place

You rarely set out to create a TSV file. It just shows up.

The most common source is copying a range out of a spreadsheet. When you select cells in Excel, Google Sheets, or Numbers and hit copy, the clipboard payload is tab-separated. Paste it into a text editor and you get columns split by tabs, rows split by newlines, with no quoting at all.

Database clients are the other big producer. The MySQL command-line client outputs query results as tab-delimited text by default. PostgreSQL's COPY ... TO with no explicit delimiter, BigQuery's bq CLI, and plenty of internal reporting scripts all lean on tabs because tabs are simple and almost never appear inside a real field. That last property is exactly what makes TSV pleasant to produce and CSV annoying to produce: commas are everywhere in real data, tabs are not.

So you end up holding TSV, and the system you need to feed (a CRM importer, an accounting package, an analytics upload form) only accepts CSV.

The Core Move: Tab to Comma, Plus Quoting

The headline operation is swapping every field-separating tab for a comma. If your data were guaranteed to be plain (no commas, no quotes, no line breaks inside any cell), conversion would genuinely be a one-line replace.

It is never guaranteed. Three cases force real work:

A cell contains a comma. Acme, Inc. is one field in your TSV. If you replace the field tabs with commas and leave that cell alone, a downstream parser counts an extra column and every row after it shifts.
A cell contains a double quote. A product name like 6" pipe has to survive the trip.
A cell contains a line break. Multi-line addresses and pasted notes do this constantly.

The CSV standard (RFC 4180) handles all three with one rule: any field that contains a comma, a double quote, or a newline gets wrapped in double quotes, and any literal double quote inside that field is written as two double quotes. So Acme, Inc. becomes "Acme, Inc.", and She said "hi" becomes "She said ""hi""".

That is the part a quick script almost always gets wrong, and it is the part that silently corrupts data, because the file still imports. It just imports into the wrong columns.

A Worked Example

Here is a four-column TSV export, with → marking the tabs:

name→note→amount→city
Acme, Inc.→net 30→1,200.50→Austin
Beta LLC→ships "fast"→990→Reno

Notice the traps: a company name with a comma, a note with embedded quotes, and an amount written with a thousands separator (also a comma). Convert it correctly and you get:

name,note,amount,city
"Acme, Inc.",net 30,"1,200.50",Austin
Beta LLC,"ships ""fast""",990,Reno

Read it field by field. Acme, Inc. and 1,200.50 are quoted because they hold commas. ships "fast" is quoted because it holds quotes, and the inner quotes are doubled. Plain cells like net 30, Austin, and 990 are left bare. Run it through the TSV to CSV Converter and the quoting is applied automatically, so you never have to reason about which cells need it.

Ragged Rows and Trailing Columns

Real exports are messy in a second way: rows do not always have the same number of fields. A spreadsheet selection can include trailing empty columns on some rows but not others. A database dump can emit a short row where a value is missing.

If a CSV importer sees three commas in one row and four in the next, it may reject the file or, worse, accept it and misalign everything. The fix is to pad short rows with empty fields so every row carries the same column count. The converter does this for you and shows a row and column summary, which is the moment to catch a stray trailing column before it reaches the target system. Those phantom empty columns from a copied range are the single most common surprise; glance at the summary first.

How I Use It

I reach for this most often during finance handoffs. Someone on the accounting side sends me a chunk pasted straight out of a spreadsheet (so, tabs), and the ledger tool they use only ingests CSV. Early on I tried to be clever with a sed one-liner that replaced tabs with commas, and it worked until a vendor name with a comma in it quietly split one row into two columns across an entire month of records. I did not notice until the import totals came up short. Now I paste the block in, let the quoting happen, eyeball the column count in the summary, and download. The whole thing takes about fifteen seconds, and I have not corrupted a finance file since.

Cleaning Up After the Conversion

Conversion is often step one. A few things usually follow:

Headers need tidying. Pasted ranges arrive with headers like Total Amount (USD) that some systems choke on. Standardize them with the CSV Header Normalizer so column names are consistent before import.
You only need some columns. If the export carries twelve columns and the target wants three, pull just those with the CSV Column Extractor instead of editing by hand.
You want a quick read on the data. Before committing an import, the CSV Stats Summary gives row counts and per-column shape so you can spot a malformed column early.
You need a readable version for a doc or PR. Turn the same data into a Markdown table with the CSV to Markdown Table tool.

If your pipeline speaks line-delimited JSON rather than CSV, the JSON Lines Formatter covers that hop instead.

A Few Practical Notes

A couple of things to keep in mind:

Encoding. CSV importers disagree about character encodings, especially with non-ASCII names. This conversion emits UTF-8 from the browser. If your target expects something else, convert encoding separately rather than hoping the importer guesses right.
Privacy. Parsing and export both run locally in your browser, so files are not uploaded. That said, the copied output and any downloaded CSV still hold whatever was in the rows; treat exports of customer or financial records as the sensitive data they are.
Delimiters are configurable. Source data is not always tab-delimited, and the target is not always comma-delimited. The shared delimiter controls read tab, comma, semicolon, or pipe, and write whichever delimiter you choose, so the same page also covers semicolon-CSV (common in European locales) and pipe-delimited feeds.

For a few hundred to a few thousand rows of one-off data, opening the converter page beats writing and debugging a parsing script. The quoting rules are handled, ragged rows are padded, and you get a file you can hand off with confidence.

Made by Toolora · Updated 2026-06-13