Convert XLSX to TSV

The reason to prefer tab-separated output is narrow and practical. Addresses contain commas. Product descriptions contain commas. Numbers formatted in half of Europe contain commas. In a comma-separated file every one of those has to be wrapped in quotes, and every consumer of the file has to implement quoting correctly to find the column boundaries again.

Tabs mostly do not occur in the data, so the delimiter and the content stop competing. The output of this conversion writes a cell reading "Widget, small" exactly like that, with no quotes anywhere on the line. `cut -f2` finds it. `awk -F"\t"` finds it. A text field in some other program finds it. Nothing has to parse; things only have to split. That is the whole difference in reliability between the two delimiters, and it is why a tab-separated file can be handled correctly by a one-line shell command while a comma-separated one needs a library that understands quoting, escaped quotes and newlines inside a field.

Tabs do occasionally end up inside spreadsheet cells — pasted from somewhere else, typed by accident, carried in from a system export. When that happens the converter writes that cell wrapped in double quotes, because the alternative is a row that silently grows an extra column.

That is correct output and a full parser handles it, but the shell tools this format is chosen for do not: `cut -f` counts tabs and knows nothing about quotes, so it sees one field too many from that row onward. If a pipeline is producing misaligned output on a handful of rows, this is almost always why. Find and remove tabs in the source sheet rather than patching downstream. The same applies to a cell containing a line break, which is common in a notes or address column and which forces the same quoting. If a sheet has free-text fields in it at all, the safer target is NDJSON, where both characters are escaped inside the value and a record can never break a line.

A workbook can hold thirty sheets. A tab-separated file holds one table with one header row, and there is no syntax in it for anything else. The conversion therefore takes the first sheet and leaves the rest, which is the only behaviour that cannot silently produce a merged file nobody asked for.

If the sheet you want is not the first, move it in the workbook and convert again — it takes less time than reading this paragraph. If you need several sheets, convert several times and keep the outputs as separate files, which is what a pipeline wants anyway: joining two files on a key is one command, and unpicking two tables that were concatenated into one is not. It is worth knowing which sheet is actually first, because it is not always the one that opens. A workbook remembers which sheet was active when it was saved, so the tab you see on opening may be the third one, and the conversion will take the leftmost regardless.

A spreadsheet does not store dates. It stores a day count and a display format, and the calendar you see in the cell is the format doing its work. Converting reads the value, not the costume, so 1 January 2024 arrives as 45292 and a timestamp arrives as that number with a fraction attached for the time of day.

The counting starts at the end of December 1899, which is why the numbers are in the forty-thousands for anything recent. Convert them where you are going — `date -d "1899-12-30 +45292 days"` in a shell, or the equivalent in whatever reads the file — rather than reformatting the spreadsheet first, because a date written as text is a new parsing problem in place of an arithmetic one. The number is also the tell that a column is a date at all. If a field you expected to hold 2024-03-11 holds 45362, nothing has gone wrong; you are seeing what the spreadsheet always held, without the formatting that was hiding it.

The header row supplies the column names, and the set of columns is the union of the keys found across every row rather than only those in the first. A sheet where a later block of rows carries an extra field still produces a file with that field in the header.

Empty cells stay as empty fields rather than disappearing, so every line has the same number of tabs and the file stays rectangular. That is exactly what a positional tool needs. It also means an empty field is genuinely ambiguous between "blank" and "not applicable", which no delimited format has ever been able to express and no converter can invent.

A code stored as text in the workbook comes out with its zeros intact: 007 stays 007, and a zero-padded account reference is unharmed. This is worth stating because the opposite is so common — a CSV opened in Excel and saved again turns those columns into numbers, and the zeros are gone before any conversion happens.

What this cannot fix is damage that was already done. If the workbook itself holds 7 because somebody imported a CSV carelessly last month, the TSV will hold 7 as well. Check a code column in the source sheet before converting; the cell alignment usually gives it away, since text sits left and numbers sit right. A column where some values are left-aligned and some are right-aligned is the worst case, because it means the column is half text and half number and no downstream tool will treat the two halves the same way.

Lines are separated by a single newline rather than a carriage-return pair, and the text is UTF-8. That is what a Unix pipeline, a Git diff and most modern importers expect. A Windows tool that insists on the other convention will still usually read it, and any tool that does not can be pointed at a converter of its own.

The output is plain text, so it also survives being pasted rather than uploaded — into a database client, a form field, a chat message, a text editor. That route is worth remembering when the destination has an import screen you do not trust and a paste box you do.

Postgres reads this shape directly with COPY, and the detail worth knowing is what it does with blanks: in its text format an empty field is an empty string, not a null, and only the marker \N means null. If the target column is numeric and the sheet has gaps, that difference is the error message you will get.

R reads it with `read.delim`, which assumes tab already, and pandas with `sep="\t"`. In every one of those, specify column types for anything that is an identifier rather than a quantity, because each of them will otherwise apply exactly the numeric inference that turned 007 into 7 in the first place.

The parsing and the writing both happen in your browser, so nothing is uploaded and there is no queue, no tier and no row limit other than your machine’s memory. A workbook of fifty thousand rows across six columns converts in a moment and produces about 1.8 MB of tab-separated text, from an .xlsx of roughly 4.3 MB.

The ceiling is the whole file being held in memory at once, which puts tens of megabytes comfortably in range and hundreds at the point where a tab strains. Past that the right tool is a streaming reader in a script rather than any browser-based converter, and saying so is better than failing halfway through a very large file.

Choose CSV instead if the destination is an import screen that names it, because a tool that says CSV frequently means it literally and will not accept another delimiter however sensible it is. Choose NDJSON if the values need to keep their types through the journey, since a delimited file has no way to distinguish the number 7 from the text "7".

Choose SQL if the rows are going into a table that already exists, and Parquet if they are going into an analytics engine that will query them repeatedly. TSV is the right answer for one specific case: text tools that split on a character, where the character must not appear in the data.