TSV to CSV Converter

It starts the same way every time. An analytics platform, a database console, or a vendor portal hands you a download with a .tsv extension, and the column you actually care about — product names, campaign labels, free-text feedback — is full of commas. You paste the file into Excel to eyeball it, and the paste splits on tabs just fine, because that is what Excel's clipboard path expects. Then you save as CSV, and the next tool that reads the file sees a nine-column header followed by rows with eleven values in them. The import chokes on row 14, which happens to be the row where somebody typed a comma into a note field.

The tempting fix is find-and-replace: swap every tab for a comma, done in ten seconds. That works for the clean 90% of files and silently wrecks the rest, because a comma inside a field value is now indistinguishable from a comma between fields. What looked like a one-character problem was never a character problem — it is a quoting problem. CSV handles data that contains its own delimiter by wrapping fields in double quotes; TSV mostly handles it by hoping the data never contains a tab. Those two philosophies do not translate into each other by simple substitution.

This converter exists for that gap. Paste or load tab-separated data, get back comma-separated data with correct RFC 4180 quoting, and — just as often needed — run the same machinery in reverse when a CSV has to become TSV for some pipeline that insists on tabs. The rest of this article walks through exactly what the tool does, why the quoting rules are what they are, and where the whole enterprise gets tricky, so you can trust the output instead of squinting at it.

A naive conversion treats the file as text and the delimiter as a token. Replace all tabs with commas, write the file, go home. Three specific things go wrong with that, and all three have bitten every one of us at least once.

First, unquoted commas in values. A product called Hammer, claw, 16 oz becomes three fields after substitution. Any downstream reader — pandas, a Postgres COPY, a Shopify importer — now sees a row with too many columns and either errors out or, worse, silently shifts data left. Second, double quotes in values. RFC 4180 gives the double quote a structural meaning in CSV, so a stray quote in an unquoted field can confuse strict parsers even when no comma is involved. Third, embedded newlines. TSV exporters love to smuggle multi-line text into fields because nothing in the tab world quotes anything; a CSV parser needs those fields wrapped in quotes or it treats each physical line as a record.

None of these are exotic. Free-text columns collect commas and quotes the way a sofa collects crumbs. The converter's real job is not the delimiter swap — it is deciding, for every field in every row, whether that field needs quoting and escaping before it is safe to write down with commas between things.

1. 1

   Load your TSV

   Drag the file onto the drop zone, or paste the raw text straight into the input pane. Pasting is handy for clipboard exports — copy a table from a browser or a spreadsheet and the clipboard text is already tab-delimited, so it drops in perfectly.

2. 2

   Check the detected settings

   The converter sniffs the delimiter to confirm the input is really tab-separated, shows a preview of the parsed first rows, and reports the detected column count. If the preview shows a ragged right edge — rows with fewer or more fields than the header — you will see it here before converting anything.

3. 3

   Pick the output direction

   TSV to CSV is the default. A toggle flips the whole pipeline to CSV to TSV for the return trip, reusing the same parser on the other side.

4. 4

   Choose your line-ending flavor

   Output can use CRLF, which RFC 4180 specifies and which maximizes compatibility with old Windows tooling, or LF, which is what version-control systems and Unix pipes prefer. Input files are accepted with either, or a mix, without complaint.

5. 5

   Convert and inspect

   The output pane renders with structural highlighting so quoted fields are visibly distinct from bare ones. Field counts per row are checked against the header, and any row that cannot be reconciled is flagged with its line number rather than quietly mangled.

6. 6

   Download or copy

   Grab the file with a .csv extension, or copy the text to the clipboard for the next step in whatever workflow sent you here. Nothing is retained after you leave the page.

Six steps, and the only judgment call you make is line endings. That is deliberate — the tool should absorb the fiddly decisions (quoting, escaping, encoding) so you can spend attention on the data itself.

TSV's paper trail is thin. The format was registered with IANA as the media type text/tab-separated-values, a registration that is essentially a one-page memo stating that fields are separated by a single horizontal tab and that, conventionally, the first line holds field names. Famously, the registration's example shows embedded tabs and newlines being escaped with backslash sequences — a convention almost no TSV producer follows and almost no consumer honors. In practice, the working contract is simpler: tab separates fields, a record ends at a newline, and nobody puts a tab inside the data because there is no reliable way to say you did.

CSV has a real specification behind it. RFC 4180, published in 2005, codifies what decades of spreadsheets had already converged on:

1. Each record is located on a separate line, delimited by CRLF.
2. The final record may or may not have an ending line break.
3. There is an optional header line of the same form as the records.
4. Within the header and each record, there is one field per column.
   Fields are separated by commas, and preceed nothing and follow nothing.
5. Each field MAY be enclosed in double quotes.
6. Fields containing line breaks, double quotes, and commas SHOULD be enclosed
   in double-quotes.
7. If a field is enclosed in double quotes, double quotes inside it are
   escaped by another double quote.

Read rules 5 through 7 together and the asymmetry with TSV becomes the whole story. CSV carries an escaping mechanism, so its delimiter is allowed to appear in the data. TSV has no escaping mechanism that anyone respects, so its delimiter must never appear in the data. Converting between them means crossing from a convention-based format into a rules-based one — and the rules have to be applied per field, not per file.

One historical footnote explains why so much software still emits TSV: tabs almost never occur in human-typed text. Databases, R, and older statistical packages leaned on that property for decades. It is a reasonable bet right up until the day someone pastes a spreadsheet formula, an address, or a chunk of log output into a field, and the bet quietly loses.

The rule set a converter must implement is small enough to fit in your head. For each field in the parsed input, in order:

def csv_field(value):
    if any(c in value for c in (',', '"', '\n', '\r')):
        return '"' + value.replace('"', '""') + '"'
    return value

That is the entire decision. A field needs quotes if it contains a comma, a double quote, a carriage return, or a newline. When it needs them, every double quote inside is doubled first, and the result is wrapped. Nothing else requires quoting — not spaces, not leading zeros, not unicode, not sadness.

Watching the rule fire on real values builds the right intuition faster than prose does:

Notice the third row. He said "hi" becomes "He said ""hi""" — the field gains outer quotes, and each interior quote is written twice. This doubling trips up hand-rolled converters constantly: people wrap the field but forget to escape, or escape but forget to wrap, and both mistakes produce files that half the parsers in the world will misread.

A conservative converter adds one more behavior: preserving leading and trailing spaces exactly as they appeared. RFC 4180 has a contested line about spaces being insignificant, so the safe move is to keep them and let quoting decisions rest on the four structural characters alone. Data that looks meaningless to you may be a sort key to somebody downstream.

Here is a small product export as it arrives from the platform — tabs between fields, and the usual chaos hiding in the free-text column. The tab characters are real tabs; they are invisible here for the same reason they are invisible in your text editor.

sku	name	price	note
A-101	Hammer, claw 16 oz	14.99	
A-102	Screwdriver set, 6-piece	24.50	Supplier calls it "multi-bit"
B-201	Tape measure	9.99	Reorder
next quarter

Three rows, and all three quoting rules get exercised. The converted output:

sku,name,price,note
A-101,"Hammer, claw 16 oz",14.99,
A-102,"Screwdriver set, 6-piece",24.50,"Supplier calls it ""multi-bit"""
B-201,Tape measure,9.99,"Reorder
next quarter"

The audit matters as much as the conversion. A conforming reader — Python's csv module, pandas' read_csv, Postgres' COPY — will parse that output into four records of four fields each, with the multi-line note intact inside row four. The physical line count changed from four to five; the logical record count did not move. That distinction, between lines on disk and records in the data model, is the entire reason embedded newlines are quoted rather than stripped.

Two small touches in the example are worth pointing at. The trailing empty note on row one becomes an empty field between two commas — legal, unambiguous, and exactly what "no value" should look like. And the price 14.99 needs no quotes because it contains none of the four structural characters; wrapping numbers in quotes is a common converter mistake that turns them into text for every downstream type inference system.

Going CSV to TSV is mechanically easier, since almost no real-world field contains a tab. The parser handles quoted CSV fields properly, unwraps them, and joins with tabs. The one genuine hazard is a field that does contain a tab — after unquoting, that tab is now a delimiter to every TSV consumer on earth. The converter surfaces those fields rather than emitting a corrupt file and wishing you luck.

The list of things that can still surprise you, honestly stated:

• BOM at the start. Excel writes UTF-8 CSVs with a byte-order mark. The converter detects and preserves it on output when the input had one, and the BOM never leaks into the first field's name.
• Mixed line endings. Files assembled by concatenation often alternate CRLF and LF. Input normalization handles both; pick one flavor for output.
• TSV that quotes anyway. A minority of exporters wrap TSV fields in double quotes. The parser accepts quote-delimited fields on the TSV side and unwraps them, rather than treating the quotes as data.
• Ragged rows. A row with fewer fields than the header is preserved as-is and flagged, not silently padded — padding guesses data, and guessing is the one thing a converter should never do.
• Semicolon CSVs. Some European locales use ; as the list separator. That is a different tool's problem; this one is strictly comma and tab, by design, so the sniffing never has to gamble.
• Very wide files. Thousands of columns are structurally fine and slow in the preview grid. The conversion itself is unaffected; the preview just gets lazy about rendering.
• Duplicate header names. Kept verbatim. Renaming headers is a data decision, not a format decision, and converters should not make data decisions.

Every item on that list has a defined behavior, which is the standard a converter should meet: surprises in your data are fine; surprises in the tool are not.

The traffic to this page comes from a handful of recognizable tribes. Analysts babysitting exports from ad platforms and BI tools, whose dashboards hand out TSV while every downstream script wants CSV. Anyone who has copied a table off a webpage — the clipboard speaks tab-delimited natively — and needs it as a .csv for an upload form that refuses pasted text.

Bioinformaticians pass through constantly, because an enormous slice of genomics tooling ships tab-separated files by tradition, while the statistical and notebook layers on either side increasingly assume CSV. Database people arrive with COPY exports: Postgres' default field separator for COPY TO STDOUT is a tab, so a quick dump destined for a spreadsheet-centric audience needs exactly this conversion.

And then there is the long tail: teachers moving gradebooks between systems, journalists reformatting public-records requests, localization teams round-tripping string tables, and the eternal category of "a vendor portal was designed by someone who hated me specifically." The format pair is old, boring, and load-bearing, which is precisely why a converter that gets the boring parts right earns its bookmark.

If your next stop is structured data rather than a spreadsheet, the sibling converters cover the adjacent routes: TSV to JSON for machine-readable output, the CSV-to-JSON equivalent when the input is already comma-side, or the fixed-width converter for the mainframe-style exports that predate both of these formats. And once the data is CSV, SQL on CSV can query it without an import step.

Four approaches people actually take, measured against the things that matter once commas show up in your data:

Find-and-replace earns its bottom row honestly: it is fast exactly until it is wrong, and it is wrong precisely on the rows you will not discover until Thursday. Excel's path works but mutates things you did not ask it to touch — import a column of long numeric IDs and enjoy your new scientific notation. The upload-based converters are competent; the objection is jurisdictional rather than technical, and if the file contains customer names or order values, that objection is the whole ballgame.

The comparison is not about raw capability. It is about which failure modes are structurally impossible in each approach, and about who gets to see your data on the way through.

The converter is a static page with a parser in it. File reading goes through the browser's File and Blob interfaces; conversion is a plain JavaScript tokenizer walking an in-memory string; output is assembled into a Blob for download. At no point does any byte of your input travel to a server, because there is no server in the data path at all — the network tab on this page will show the initial load and then silence.

That has a practical corollary beyond confidentiality: once the page is loaded, it works offline. On a plane, behind a locked-down corporate proxy, or in a facility where the export cannot legally touch the internet — a customer list under NDA, patient-adjacent data, anything GDPR-flavored — the conversion still runs, because everything it needs is already on your machine.

This is the only architecture a delimiter converter should have. A format with no computation and no external truth to consult has no defensible reason to make a network round-trip, and tools that demand one are collecting something other than good will.

Sibling converters in the same cluster cover the neighboring routes: TSV to JSON when the destination is an API or a script, CSV to JSON Converter for the comma-native equivalent, and Fixed Width to CSV for column-positioned exports that predate delimiters entirely. For analysis rather than format juggling, SQL on CSV runs real queries over the converted file without ever standing up a database.