CSV vs XLSX: which format to use, and when

One sentence covers most of it: CSV is a text file with commas in it; XLSX is a zipped folder of XML that only a spreadsheet program understands. Almost every practical difference falls out of that.

The useful question is rarely "which is better". It is "which one am I handing to whom, and what will it survive on the way".

The fast answer

• Handing data to a program — an import, an API, a script, a database: CSV.
• Handing a document to a person — formatting, formulas, several sheets: XLSX.
• The file is large (say, over 100MB or 500,000 rows): CSV.
• The values must come back exactly as they went in — postcodes, product codes, phone numbers, long IDs: CSV, and say so, because the receiving spreadsheet is what will mangle them.

What each one actually is

A CSV is one line per row, values separated by commas, quotes around any value containing a comma. You can read one in a text editor. You can write one with echo. There is a specification — RFC 4180 — and near-universal agreement to ignore parts of it, which is why delimiters vary by country and why broken CSVs are a whole topic of their own.

It stores values, and nothing else. No types, no formats, no formulas, no colours, no second sheet. A cell containing 007 and a cell containing the number seven are indistinguishable once written: both are just the characters between two commas, and what happens next depends entirely on what reads them.

An XLSX is a ZIP archive. Rename one to .zip, unpack it, and you get a directory of XML: one file per worksheet, a shared-strings table, a styles table, relationship files. It stores everything a spreadsheet knows — cell types, number formats, formulas and their cached results, charts, conditional formatting, frozen panes, macros in the .xlsm variant.

Side by side

Two rows there deserve expanding.

Size, and why the answer flips

XLSX compresses, so for the same data it is usually smaller on disk — often three or four times. That makes CSV look like the wrong choice for big data, which is backwards.

What matters for a large file isn't disk size, it's what happens on open. XLSX must be decompressed and parsed into an object model before you see row one; the whole thing lands in memory. A CSV can be read a line at a time, so a tool can stream a 5GB file it could never hold. That is why every "handle this file with DuckDB" answer starts with a CSV and why the row ceiling above matters: an export of three million rows cannot be an XLSX in one sheet, at any size.

Types, and the round trip that eats your data

This is the difference that actually costs people work.

Because CSV carries no types, a spreadsheet has to guess on import. The guesses are consistent and consistently wrong in the same four ways:

• 01234 becomes 1234 — leading zero stripped from a postcode.
• 4019283746501928 becomes 4.01928E+15 — an ID in scientific notation, and the last digits are gone, not hidden.
• 3/4/2026 becomes March 4th or April 3rd depending on locale.
• MAR1, SEPT2, DEC5 become dates. Gene researchers renamed 27 human genes in 2020 because of this.

Open a CSV in Excel, save it back as CSV, and those changes are now permanent in the file. The CSV didn't lose the data. The spreadsheet you opened it with did. Which is the case for reading a CSV with something that reads it as a CSV, rather than as a spreadsheet document:

CSV File Viewer - Smart CSViPhone & iPad · Android

Reads the file as a CSV rather than importing it: no type coercion, no locale date guessing, and SQL or plain-language questions against the values as written.

What it does

Choosing, by situation

Use CSV when:

• Something automated is on the other end — a database import, a script, an API.
• The file is large, or growing.
• The data must round-trip byte-for-byte.
• It goes into version control and you want to see what changed.
• You need it readable in a decade with no assumptions about software.

Use XLSX when:

• A person is opening it, and layout is part of the message.
• There are formulas that need to stay live.
• The data is genuinely multi-sheet.
• Cell types matter and you cannot control what opens it — which is the honest argument for XLSX: types the receiver can't get wrong.
• You need charts, filters or conditional formatting inside the file itself.

Use neither when: the dataset is bigger than a spreadsheet and you'll query it repeatedly. That is Parquet's job, or a database's. Parquet is columnar, typed and compressed, and both DuckDB and pandas read it natively.

Things people get wrong about this

"CSV is an Excel format." It isn't; Excel merely opens it, which is why the type coercion above happens. CSV predates Excel by two decades.

"XLS and XLSX are the same thing." XLS is the pre-2007 binary format, still turning up from old systems. XLSX is the OOXML replacement. If you're handed an .xls, convert it — modern Excel opens it with warnings and some tools refuse outright.

"XLSX is safer because it's a real format." XLSX carries macros, external links and DDE payloads; CSV is inert text — apart from formula injection, where a value starting with =, +, - or @ gets executed by the spreadsheet that opens it. Both need care, in different directions.

"Converting is lossless." Going XLSX → CSV drops every formula (you keep the last computed value), every second sheet, and all formatting. Going CSV → XLSX adds types that were never in the data — which is where the mangling happens. Converting a CSV to Excel on a phone covers how to do that without the damage.

The one habit worth having

When you send someone a CSV containing codes, IDs or dates, say so in the message: "open this with an import step and set the ID column to Text". Two lines of email prevent the single most common data-quality failure in office work, and no choice of format prevents it on its own.