CSV vs TSV

The short answer

The same format with a different separator, and the difference matters more than it sounds. A comma appears constantly in real data — in names, addresses, prices in much of Europe — so a CSV field containing one has to be quoted, and quoting brings its own escaping rules and its own failures. A tab appears in data almost never.

So TSV is the more robust choice for anything moving between programs, and CSV is the more universal one: it is what spreadsheets export by default and what most systems expect on import. TSV also has one practical advantage worth knowing — paste it into a spreadsheet and the columns land correctly with no import dialogue at all.

Worth knowing regardless of which you choose: neither format has a specification everyone follows, so both are really families of near-compatible conventions. Line endings, quoting, and whether the first row is a header are all things that vary, and most of the trouble people have with these files comes from those rather than from the separator.

Side by side

Where they actually differ

• They are 21 years apart, and most of what separates them is what had been learned in between.

Which to choose

Choose CSV when

Choose CSV when the file is going somewhere that expects it, which is most places, and when the data has few commas in it.

Choose TSV when

Choose TSV when fields contain commas, when quoting has already caused a problem, or when you want to paste straight into a spreadsheet.

Converting between them

• CSV to TSV converter
• TSV to CSV converter

Common questions

Which handles fields containing the separator better?

Neither handles it well, but TSV needs to far less often. CSV's answer is to wrap the field in quotes and double any quotes inside it, which works until a file is produced by something that gets it slightly wrong. TSV's answer is that a tab inside a field is rare enough to be a non-problem — though when it does happen, TSV has no standard escape at all.

Which of CSV and TSV is better?

Neither, in general — if one were simply better the other would have disappeared. They are good at different things, and the short answer above says which is which. The useful question is what the file has to do next: be edited, be published, be opened by somebody else, or fit inside a size limit.

Does converting between them lose anything?

It depends on the direction. Converting into a format that stores everything loses nothing but does not recover anything either; converting into one that discards detail loses a little each time. The table above says which of these two does which.

Can I convert back afterwards?

The file will convert back, but whether it comes back unchanged depends on the direction. Between two formats that store everything, a round trip is lossless. Where one of them discards detail, that detail is gone and the return journey cannot invent it.

Can I use both?

On a web page, often yes, and it is usually the right answer: serve the smaller modern format and list an older one as a fallback so each browser takes what it understands. For a file you are handing to a person, pick one — the one they can open.

Which one does my software support?

The side-by-side table above says which browsers read each, which is the part that varies most. Desktop support is harder to state in general and tends to lag browsers by years, so if the file is going to somebody else, the older and more widely read of the two is the safer choice.

Is converting between them free?

Yes, with no account and no limit on how many files you convert. Every converter linked from this page runs in your browser: the file is read from your device, converted by code running on it, and handed back as a download.

Is my file uploaded?

No. There is no conversion server here to upload it to, and no third-party service is involved. You can confirm it yourself: open your browser's developer tools, switch to the Network panel with no filter, and run a conversion — no request carries your file.