CSV vs TSV: Delimiters, Quoting, Encoding, and When to Use Each

When you export data from a spreadsheet or pass data between systems, you often run into CSV and TSV. Both are "files that represent a table as text" and look alike, but they differ in their delimiter and in how they handle values, so each suits different situations. This article explains the differences starting from the delimiter, shares tips to prevent garbled text and import mistakes, and finishes with a comparison to JSON.

What CSV and TSV Are

CSV (Comma-Separated Values) and TSV (Tab-Separated Values) are both text formats that express tabular data with a simple rule: one line is one record, and each item within a line is separated by a delimiter. Because they are plain text, you can inspect them in a basic editor like Notepad without special software, and almost any language or tool can read and write them.

The essential difference between the two comes down to a single point: whether the delimiter that separates items is a comma (,) or a tab. For example, lining up the three items "John Smith," "Tokyo," and "30" gives "John Smith,Tokyo,30" in CSV, and "John Smith[tab]Tokyo[tab]30" in TSV. Because the mechanism is so simple, details like quoting and encoding (covered below) have a big effect on how easy they are to work with in practice.

When you want to check how an actual file is structured, paste it into the CSV Viewer and view it laid out as a table; that makes the differences easy to grasp.

The Delimiter Difference: Comma vs Tab

The biggest thing separating CSV and TSV is the delimiter. Each has strengths and weaknesses.

CSV is the most widespread format and is supported broadly by spreadsheets, databases, and the import/export of many services. On the other hand, it is not unusual for the data itself to contain commas, such as addresses, amounts, or free text; in that case the delimiter and the value can no longer be distinguished, so you need the quoting workaround described below.

TSV uses a tab as the delimiter. Its advantage is that it rarely clashes with the delimiter even for data that tends to include commas, such as English or Japanese sentences and addresses. Since tabs seldom appear inside sentences, it is often simpler to handle. The downside is that a tab looks like whitespace on screen and is harder to spot than a comma, and depending on editor settings it can be accidentally converted into spaces.

When Values Contain Commas or Line Breaks: Quoting

The most common source of trouble in CSV is a case where the value itself contains a delimiter or a line break. For example, if an address contains a comma like "Chiyoda-ku, Tokyo," what should be a single item gets split into two.

To prevent this, CSV has a rule to enclose values in double quotes ("). RFC 4180, the de facto standard, defines it as follows.

• If a value contains a comma, a line break, or a double quote, enclose the entire value in double quotes.
• If a double quote itself appears inside the value, escape it by doubling it ("").
• Once enclosed in quotes, a value can contain a line break and still be treated as a single item.

"Chiyoda-ku, Tokyo","Note: ""important""",30

In this example, the first item is quoted because it contains a comma, and the second item has its inner double quotes escaped by doubling. Many of the defects that arise when reading and writing CSV are caused by missing this quoting logic. If you write naive code that simply "splits on commas," it will also split commas inside quotes and corrupt the data.

With TSV, on the other hand, a comma inside a value causes no problem because the delimiter is a tab. The handling of tabs or line breaks inside values is not standardized, so depending on the workflow you may remove tabs and line breaks from values in advance or replace them with another character. When you want to tidy the contents before importing, it helps to confirm how things are actually split using the CSV Viewer.

Encoding and Excel Import Pitfalls

Because CSV and TSV are text files, differences in character encoding are a major cause of garbled text. UTF-8 is the standard today, but in Japanese environments files in the older Shift_JIS encoding are still common. If the encoding of the file you received differs from the encoding the opening software assumes, the text will be garbled.

One pitfall to watch in particular is importing CSV into Excel. When you open a file by double-clicking, Excel may, depending on the environment, fail to detect UTF-8 correctly and show garbled characters. The following approaches help avoid this.

• Save as UTF-8 with a BOM: adding a BOM marker at the start of the file makes Excel more likely to recognize it as UTF-8.
• Import from the "Data" tab: instead of double-clicking, specify the file with the get-data feature and explicitly choose the encoding and delimiter.
• Check the delimiter: depending on regional settings, Excel may treat something other than a comma (such as a semicolon) as the delimiter.

Also, numbers that begin with a zero, such as phone numbers, postal codes, or product codes, can have their leading zeros stripped because Excel treats them as numeric values. Long numbers can also turn into scientific notation (like 1.23E+11). Prevent this by telling Excel to treat such columns as text, or by setting the column format to text during import. Differences in line-break codes (Windows CRLF vs Unix-style LF) can also cause extra blank lines or read errors in some environments.

When TSV Is Handy and How to Choose

So how should you choose between CSV and TSV? The main axes are "does the data contain commas" and "what does the other side expect."

When TSV fits

TSV is comfortable when handling data that tends to contain commas, such as addresses, names, comments, and product descriptions. The delimiter is unlikely to break without relying on quoting, which makes it easier for machine processing such as database imports and log handoffs. A practical bonus: when you copy a cell range from a spreadsheet, the clipboard actually holds it as tab-separated text, so TSV pastes nicely into an editor.

When CSV fits

CSV is the safe choice when the destination software or service assumes CSV, or when you want to distribute data broadly. Support is wide, and "just send CSV" still works in many situations. When values contain commas, the prerequisite is to perform quoting correctly.

When in doubt, the basic rule is to match whatever format the other side specifies. When you need to convert between formats, a tool like the JSON CSV Converter lets you convert safely while avoiding manual replace-and-replace mistakes.

Comparison with JSON

Alongside CSV and TSV, JSON is widely used for exchanging data. The three excel at different things.

CSV and TSV are ideal for representing a flat table of rows and columns. The data is light and opens directly in a spreadsheet, so they suit handing off and aggregating large lists of records. The flip side is that they are poor at nested structures, such as holding a further list or object inside a single item.

JSON can nest objects and arrays to express hierarchical data naturally. It suits structurally complex data like API responses and configuration files, but it needs conversion to open directly in a spreadsheet, and for a simple table the repeated key names tend to make the file larger.

In practice you frequently face conversion scenarios such as "I want to aggregate JSON received from an API in a spreadsheet" or "I want to turn table data into JSON to handle it in a program." For that, using the JSON CSV Converter maps the structures automatically and is more reliable than doing it by hand. It is not about which of CSV, TSV, and JSON is superior; the right approach is to choose by the shape of the data: CSV/TSV for flat tables, JSON for hierarchy.

Please note that this article is intended to provide general information. Actual file specifications and support can vary by software and service, so make your decision after checking the latest official documentation.