Tab-separated and comma-separated files are siblings, and siblings cause confusion. Both store tables as plain text, one row per line, with a character separating the values in each row. In a TSV file that character is a tab; in a CSV file it is a comma. The conversion therefore sounds like a find-and-replace: swap every tab for a comma, and you are done. That works until the first field contains a comma, a tab, a quotation mark, or a line break, and then the naive swap corrupts the data in ways that look fine until the file is opened in another program, where columns shift, rows split, and values land in the wrong place.

The reason is that both formats have quoting rules, and those rules are the actual format, not decoration. In CSV, a field containing a comma, a quote, or a line break must be wrapped in double quotes, and a double quote inside a quoted field is doubled. In TSV, tabs inside fields are the equivalent problem, and they are handled by quoting or by escaping, depending on the producer. A converter must understand these rules, not just swap characters: it must parse the TSV into fields, respecting whatever quoting or escaping the source used, and then write those fields as CSV, applying CSV quoting where the values require it. The TSV to CSV Converter performs that parse-and-rewrite, so the conversion preserves fields rather than characters.

How the tool works

Conversion has two distinct stages, and confusing them is the source of most errors. Parsing reads the TSV text and splits it into rows and fields, honouring quoted sections and escaped characters, so a tab inside a quoted field stays part of that field instead of splitting it. Writing takes those fields and emits CSV, choosing for each field whether quoting is needed: a plain value like "Laptop" needs no quotes, while a value like "Desk, oak" needs them, because the comma inside it would otherwise be read as a separator. A field containing a double quote needs quoting plus doubling of the quote, so the value 'say "hi"' becomes "say ""hi""" in CSV. That triple-quote ending looks like a typo to the uninitiated, but it is correct: an outer pair of quotes marking the field, with the inner quote doubled.

Two details of parsing deserve attention. First, header handling: the first row of a TSV is usually a header, and it should survive conversion as the first row of the CSV, with its field count matching every data row. A row with fewer or more fields than the header is a warning sign, not a rounding error, and a good converter either reports it or preserves it faithfully so you can find it, rather than silently padding or truncating. Second, line endings and trailing tabs: a trailing tab on a row means a final empty field, not nothing, and a file with mixed line endings can split rows in unexpected places. Preserving field counts across the conversion is the simplest verification that the parse was correct, and it catches more errors than eyeballing the output.

The converter fits into a family of tabular tools. The CSV to TSV Converter performs the reverse trip, the CSV Cleaner repairs common CSV messes after conversion, and the CSV to JSON Converter is often the next step when the converted CSV needs to feed a program rather than a spreadsheet.

A worked example

Consider a small, clearly-labelled sample TSV with three rows: a header row "name", "note", "price", and two data rows. The first data row is "Laptop", "Fast, light", "999". In TSV form, the note field contains a comma, but that is harmless in TSV, because the separator is a tab, not a comma. The second data row is "Desk", a note containing a tab character inside quotes, written as "Oak\t finish" in the source, and "450". A naive tab-to-comma swap would split that note into two fields, giving the second row four fields instead of three, and every column after the split would shift left by one in any program reading the result.

A correct conversion parses first and writes second. The header becomes name,note,price. The first data row becomes Laptop,"Fast, light",999, with the note quoted because it contains a comma. The second data row becomes Desk,"Oak\t finish",450, with the note quoted because it contains a tab, which CSV readers treat as ordinary content inside quotes. The exact CSV output is therefore (where \t stands for one tab character, shown visibly because a real tab is invisible on the page):

name,note,price Laptop,"Fast, light",999 Desk,"Oak\t finish",450

Three rows, three fields each, and every value in its original column. The verification is simple and worth doing every time: count the fields in each output row and compare with the header, and spot-check any field that contained a comma, quote, tab, or line break in the source. If the field counts match and the awkward fields survived intact, the conversion is sound. If a row has the wrong count, the parse went wrong somewhere, and the fix belongs in the parsing stage, not in patching the output by hand.

A second worked detail concerns quotes. Suppose a TSV field contains the value: say "hello". Written as CSV, that field must be quoted, and the inner quote doubled, giving "say ""hello""". If the converter instead wrote say "hello" unquoted, a CSV reader would see the quote as the start of a quoted section and misread everything after it, possibly swallowing the rest of the row. Quote handling is invisible when values are plain and decisive when they are not, which is why testing a converter with awkward values matters more than testing it with clean ones.

Common mistakes

The most common mistake is swapping delimiters with find-and-replace instead of parsing. It works on clean data and corrupts awkward data, and awkward data is precisely the data that matters, because it contains the commas and quotes that real-world notes and addresses always contain.

A second mistake is converting without checking field counts. A row that gains or loses a field has been corrupted, even if the file still opens. Count fields per row after every conversion, and investigate any mismatch before using the file.

A third mistake is assuming the source TSV is well formed. Some TSV producers do not quote tabs inside fields at all, in which case no converter can recover the intended field boundaries with certainty. When the source is malformed, the honest fix is to repair the source or re-export it, not to hope the converter guesses correctly.

A fourth mistake is converting twice through intermediate formats. Each conversion is a chance to lose quoting or encoding information, especially with non-ASCII characters. Convert once, directly, from the source to the target format, and verify that result.

Honest limitations

A converter translates between formats; it cannot repair a malformed source, recover field boundaries that were never marked, or know what a value was supposed to be. If the source TSV contains unquoted tabs inside fields, the conversion is ambiguous, and any output is a best guess, not a faithful translation. The tool also cannot detect semantic errors, such as a price stored as text or a date in an unexpected format; those survive conversion unchanged, because conversion preserves values, it does not validate them. Encoding is a further limit: a source file in an unusual encoding may convert with garbled characters, and that problem must be fixed at the encoding stage, before or during conversion, not after.

Closing

Convert by parsing, not by swapping characters, and verify by counting fields and spot-checking the awkward values. The TSV to CSV Converter handles the parse-and-rewrite, the CSV to TSV Converter covers the reverse trip, and the CSV Cleaner repairs the messes that slip through. For the reverse conversion explained from the other side, CSV to TSV Converter: Tabs Instead of Commas walks through the same rules in the opposite direction. A converted file whose field counts match is a file you can trust, and that check takes less than a minute.