Tab-Separated Values (TSV) Converter

Introduction

Tab-separated values, usually shortened to TSV, store one record per line and split fields with tab characters. That plain-text shape makes TSV easy to move between spreadsheets, scripts, and import jobs, but it also makes the structure easy to damage. One missing tab, one extra line break, or one wrong header decision can shift every field that follows.

The narrow TSV definition is stricter than many files people receive in practice. A baseline TSV file is expected to keep the same field count on every row, treat the first line as field names, and avoid literal tabs inside field values. Real exports often drift away from that ideal. A file may still arrive with a TSV label even when it contains blank lines, duplicated headings, quoted cells, or identifier columns that should stay text.

This converter is most useful in that inspection stage before a bad parse turns into a bad handoff. Paste the text or drop a .tsv or .txt file and the page immediately shows row count, column count, header status, delimiter choice, dominant column types, preview limits, and structural warnings. That gives you a quick read on whether the table is trustworthy enough to export.

If the structure looks right, the same parsed grid can then be copied or downloaded as JSON, JSON Lines, SQL, XML, HTML, Markdown, CSV, DOCX, or XLSX. You can also separate visible column labels from machine-facing keys, which helps when the source headings are blank, duplicated, or awkward to reuse in automation and database work.

Parsing, previewing, and text-based exports stay in the browser. The DOCX and XLSX paths load browser-side libraries only when you request those formats, then generate files from the current parsed rows. For sensitive data, the main boundary to think about is your browser session plus any file you choose to download or share afterward.

Technical Details

The page starts by normalizing line endings so pasted Windows, Unix, and mixed-text exports behave the same way. Delimiter handling is explicit when you choose comma, semicolon, tab, pipe, space, or a short custom separator. In automatic mode, the parser samples the opening non-empty lines and scores common delimiter candidates by how consistently they produce multi-field rows. That means the tool can recover from files that are called TSV but were actually exported with another separator.

Parsing itself is character-based rather than a naive split on tabs. You can choose double quotes, single quotes, or no quote handling at all, and you can decide whether embedded quote characters are escaped by doubling them or by using backslashes. That matters when a cell contains a delimiter-like character or an embedded newline. If a quoted field never closes, the run stops with a specific end-of-file quote error instead of guessing where the row should end.

After parsing, the tool measures the widest row and pads shorter rows with empty strings so the preview and export grid stay rectangular. It also keeps warning messages for the rows that did not match the widest width. Skipping empty rows, trimming fields, and preview-row limits all change how easy the table is to inspect, but the preview limit affects only the on-page table. The full parsed dataset is still used when you copy or download an export.

Header detection is heuristic when you leave Header row on automatic. The first row is compared with up to twelve later non-empty rows using shared field-name keywords, uniqueness, value-shape differences, proper-name penalties, numeric and date-like patterns, and broad type-distribution changes. That gives the page a sensible first guess, but it is still a guess. If the first row is real data, not labels, switch the header mode before trusting JSON, SQL, or any other keyed output.

Typed conversion is intentionally narrow. With Detect data types enabled, the page can turn numeric tokens into numbers, true/false and yes/no into booleans, and literal null or undefined markers into nulls. Blank fields become null only when Empty as null is enabled. Date normalization is stricter still: the page only converts ISO-like values when Detect dates is turned on, which helps avoid accidental coercion of regional date strings and identifier-like values.

Column overrides split human-readable labeling from machine-friendly naming. Display labels control the preview table and document-style exports. Key overrides influence object-style JSON more directly, then feed sanitized identifiers for XML tags, profile keys, and SQL columns. JSON Arrays are always row-based, while JSON, JSON Lines, and SQL depend on an active header interpretation. XML, HTML, Markdown, CSV, DOCX, and XLSX can still be produced without a real header row, although they may fall back to generated column names.

Everyday Use & Decision Guide

The safest default is conservative. Start with the source text, leave the delimiter on tab or automatic, keep header mode on automatic, and read the summary badges before you touch an export tab. If row count, column count, or the delimiter badge looks implausible, stop there. A clean-looking JSON or spreadsheet download is not helpful if the parser already split the rows incorrectly.

The Data tab answers one question: did the page reconstruct the table shape you expected? The Profile tab answers a different question: do the columns behave the way you expected after typing rules were applied? For casual review, the first question may be enough. For any keyed or typed export, you need both answers to be right.

Choose the export by downstream job, not by habit. JSON Arrays work well when row position matters. JSON and JSON Lines are better when each field needs a stable name. SQL is useful when you want a quick insert script for a scratch table. HTML, Markdown, DOCX, and XLSX are the better choices when a person still needs to review, edit, or approve the content. The table-level CSV export is a clean copy of the current preview grid, not a verbatim reproduction of the original TSV text.

This page is a strong fit for structural triage and format conversion. It is not a semantic validator. A column that profiles as numeric is not automatically a valid account number, and a timestamp that parses cleanly is not automatically in the right timezone or business meaning for your system.

Step-by-Step Guide

1. Paste the source text or drop a .tsv or .txt file into the input box.
2. Read the summary badges first. Confirm the row count, column count, header status, and delimiter label all look plausible.
3. If the table shape is wrong, fix Delimiter, Quote character, or Escape style before doing anything else.
4. Set Header row explicitly if the automatic guess is wrong, then use the column naming panel if you need clearer display labels or better export keys.
5. Review Detect data types, Detect dates, and Empty as null with the Profile tab open so you can see what changed.
6. Check any warning badges for irregular row lengths, duplicate headings, missing headings, or preview trimming.
7. Open the target export tab and compare one sample row with the Data tab before copying or downloading the final output.

Interpreting Results

Think of the summary strip as a structural health check. Header detected and the delimiter badge are the two signals that most strongly affect everything downstream. If either one is wrong, the rest of the page will still look busy and useful, but it will be describing the wrong table.

The Profile tab is where most hidden mistakes show up. Non-empty counts tell you how many rows carry actual content after trimming and null handling. Null counts include explicit null-like markers and blanks only when Empty as null is turned on. Empty counts reflect blank strings that stayed blank. The sample value is the first meaningful cell the profiler found in that column, which makes it a fast spot-check when a dominant type alone feels too abstract.

Unique counts are useful, but they are intentionally capped. The profiler only tracks up to 256 distinct values per column for speed, so a reported uniqueness value near that ceiling should be read as a quick diversity indicator, not a full-cardinality audit. If a column matters for keys, billing, or identity, check the raw data directly rather than relying on the capped uniqueness figure alone.

A successful parse is not the same as a safe downstream import. Spreadsheet software can still evaluate formula-like cells, SQL imports can still fail on business rules or schema mismatches, and XML tag cleanup can still rename awkward headings. The right habit is to compare one source row, one profile row, and one exported row before you treat the conversion as finished.

Worked Examples

Auditing a project-hours extract

A team paste includes columns such as id, name, team, active, score, and updated_at. The page detects the first row as a header, keeps the row count stable, and profiles active as boolean plus score as numeric. If you also enable date detection, ISO timestamps can be normalized for record-style exports. At that point JSON, JSON Lines, or SQL are reasonable choices because the column structure is already settled.

Fixing a mislabeled vendor file

A supplier sends a file called TSV, but the preview shows one giant column. Changing the delimiter to semicolon reveals the real table immediately. A second pass with quote handling keeps an address or notes field intact even though it contains punctuation and line breaks. The warning badges then tell you whether a few rows are still short or whether the file is structurally clean enough to export.

Preserving codes with leading zeros

A parts list contains item codes such as 00127 and 00045. With type detection enabled, those values can become plain numbers in typed outputs. The safer move is to disable Detect data types, recheck the profile, and confirm that the codes now remain text before you copy JSON or build a SQL script.

Preparing a documentation table

Sometimes the job is not machine import at all. You may only need a readable table for a report or knowledge base. In that case, keep the parsing rules correct, adjust display labels for readability, and export HTML, Markdown, DOCX, or XLSX. That path keeps the original rows visible to humans without forcing you into record-style naming that the document does not need.

FAQ:

Glossary:

Delimiter

The character or short token used to separate one field from the next.

Header row

The first row when it is interpreted as column labels instead of ordinary data.

Keyed record

A row expressed as named fields, such as a JSON object or a SQL insert tuple tied to column names.

JSON Lines

A newline-delimited stream where each row is one JSON object on its own line.

Null

An explicit missing value, different from an empty string.

Profile

The per-column summary showing type, counts, uniqueness signal, and a sample value.