CSV vs XLSX: Plain Rows or a Real Workbook?

By Andrew Butson · July 2, 2026 · 8 min read

CSV and XLSX both end up holding a grid of rows and columns, which is why they get treated as interchangeable. Export a report as either one, right? Under the surface they are built on completely different assumptions. A CSV file has no idea what any of its values are; every entry is just a string of characters between commas, and it is up to whatever opens the file to guess what a column means. An XLSX file already knows: each cell was written down as a number, a date, a boolean, text or a formula, and it stays that way until someone changes it.

That single difference, no types at all versus explicit types in every cell, explains almost everything else in this comparison: why CSV is small and universal, why XLSX can hold formulas and multiple sheets, and why the classic list of 'Excel ruined my CSV' complaints (vanished leading zeros, flipped dates, mangled account numbers) happens to CSV files specifically, and essentially never to XLSX ones.

What a CSV actually guarantees

A CSV file is rows of plain text with commas between the values and, by convention, a header row naming the columns. That's the entire format: there's no header for column types, no distinction between a cell holding "42" the number and "42" the string, and no way to store more than one table per file. What that minimalism buys you is universality: any programming language can write a CSV in a few lines, any database can import one, and it opens in a text editor as readily as a spreadsheet. It is also naturally diffable, because it's plain text: version control tools show you exactly which rows and fields changed between two versions, something a ZIP-based binary format like XLSX can't offer in any readable form.

CSV also comes with zero vendor lock-in. It isn't owned by Microsoft, LibreOffice or anyone else, and a file written on one system needs no special library to be read correctly on another, as long as both sides agree on the same delimiter and quoting rules (RFC 4180, formalised in 2005, wrote those conventions down, though older files sometimes bend them). What CSV cannot do is carry any of the things a real workbook needs: it has no formulas, no formatting, no multiple sheets, and nothing that tells the next program what a column is actually for.

What XLSX adds on top

Rename an .xlsx file to .zip and unpack it, and the trick behind the format becomes obvious: it's a ZIP archive holding a set of XML files, one per worksheet, plus a shared-strings table, a styles part and relationship files tying it all together. That packaging is what lets XLSX hold an entire workbook rather than a single table: multiple named sheets, each with its own grid, cross-referencing each other through formulas.

The more important difference for day-to-day use is that every cell in an XLSX is typed. A number, a date, a boolean and a formula are all stored as distinct things, not as look-alike text. A formula cell keeps both the expression itself and the value it last calculated, so another program can display a result without recalculating the whole sheet. On top of that sits everything CSV has no way to represent at all: currency and date display formats, conditional formatting, frozen panes, charts and defined ranges. None of that is decoration for its own sake — it's the reason XLSX is a document you work in, where CSV is a format you pass through.

The failure modes that only happen to CSV

The classic complaints about "Excel corrupting my data" are really a CSV problem wearing an Excel costume. Because a CSV carries no type information, double-clicking one hands it to Excel's default text importer, which has to guess every column's type from its content and your machine's regional settings. It then applies that guess as a real, destructive change, not just a different display. A product code of 00214 loses its leading zeros because numbers don't have leading zeros. A date written as 3/4 becomes 04-Mar or 03-Apr depending on whether the machine reading it expects month-first or day-first, because the guess uses the Windows short-date format rather than anything in the file. And because Excel stores every number as a 64-bit float with about fifteen significant digits, a sixteen-digit account number or barcode gets rounded and flipped into scientific notation, with the digits past the fifteenth gone for good, not just hidden.

None of that can happen to an XLSX opened the normal way, because there's no guessing left to do by the time the file is opened: the type was decided when the cell was written. That's exactly why converting a CSV to XLSX properly, rather than just renaming it, fixes the problem at the source: a value only becomes a numeric cell if it's a clean integer or decimal that Excel can store exactly, and anything else, such as IDs with leading zeros or numbers with more digits than Excel's precision can hold, is written as an explicit text cell instead. Opening that .xlsx afterwards never runs Excel's guess-based importer at all.

Converting between the two

Going from CSV to XLSX is a promotion: Morphr writes each value into a typed cell rather than leaving it as ambiguous text, which is the only way to stop Excel's importer from mangling dates, IDs and long numbers the moment someone double-clicks the file. Going the other way, from XLSX to CSV, is a demotion, and an intentional one: you get the values from the first sheet as plain rows, with formulas exported as the numbers they currently show rather than the calculations behind them, and every other sheet, chart, colour and format left behind because flat text has nowhere to put them. Neither direction is lossy in the sense of destroying data you asked to keep; each one simply produces exactly what its target format is capable of holding.

Frequently asked questions

Does converting CSV to XLSX fix the leading-zero and date problems?

Yes, for the same reason importing through Excel's wizard does: it decides each cell's type before the file is ever opened casually. Morphr writes a value as a numeric cell only when it's a clean integer or decimal Excel can store exactly; anything else, including IDs with leading zeros, is written as text, so there's no guess left for Excel to get wrong.

Why does the same CSV show different dates on different computers?

Because a CSV has no way to record that a value is a date, Excel's importer parses date-shaped text using your machine's regional short-date format. A US-configured PC and a UK-configured one can read the identical file as two different dates. Converting to XLSX first removes the guess, because the cell is already typed.

What happens to formulas when I convert XLSX to CSV?

They are exported as the value they currently show, not the calculation behind them. CSV has no concept of a formula, so the underlying expression is gone once you export. Keep the original XLSX if you might need to edit the formula later.

Is XLSX just a bigger, better version of CSV?

No. They solve different problems. XLSX can do things CSV structurally cannot, like multiple sheets and live formulas, but that richness makes it a poor transport format: it's larger, it isn't plain text, and it can't be diffed or read by a tool that just wants rows of values. CSV's plainness is a feature when the job is moving data, not presenting or calculating with it.