You double-click a CSV, Excel thinks for ninety seconds, and then one of three things happens. It opens something that is obviously not your whole file. It shows a dialog saying File not loaded completely. Or it stops responding and you go and make coffee.
None of those mean the file is broken. They mean the file is bigger than the thing you opened it with. Here is how to see inside it anyway, with the tools that handle it properly on a desktop, and the ones that work when the file is sitting in your email on a phone.
The fast answer
- On a desktop, just to look and query: use DuckDB. One command, no import step, handles gigabytes.
- On a desktop, staying in Excel: load it through Power Query into the Data Model, not into the grid.
- On a phone or tablet: use a CSV app built for big files: Smart CSV Viewer to read and query, CSV Editor to change rows.
- Never: open it in Notepad, and never save over your original from a tool that only loaded part of it.
The rest of this explains why Excel gave up, how to tell what you are dealing with, and which of those routes fits your file.
Why Excel won't open it
Excel has hard structural limits, and they are not negotiable by buying more RAM:
- 1,048,576 rows. That is 2²⁰, and it is the height of a worksheet. A file with 3 million rows cannot fit in one sheet, at any price.
- 16,384 columns. Rarely the problem, but wide exports from analytics tools do hit it.
- 32,767 characters per cell. A CSV with a long JSON blob or a full email body in one field will get silently clipped.
- Memory. Well before the row limit, Excel slows to a crawl. A 400MB CSV can expand to several gigabytes in memory once every value is parsed, typed and indexed.
The dangerous failure is the quiet one
A file that refuses to open is annoying. A file that opens is the one that costs you.
When a CSV exceeds the row limit, Excel loads the first 1,048,576 rows and warns you once. If you dismiss that dialog, filter down to what you needed, and save, you have just written a file that is missing every row past the cut, with no visible sign that anything is wrong. The column headers are right. The data looks right. It is simply not all there.
The same is true of a lot of lightweight CSV viewers, including several mobile ones: they read the first few thousand rows to keep the interface responsive and never mention it. Before you trust any tool with a big file, check that its row count matches the count in the source file.
First, find out what you have
Two numbers decide everything that follows: how big the file is, and how many rows it holds.
On macOS or Linux:
ls -lh big.csv # file size
wc -l big.csv # row count (add 1 for the header)
head -5 big.csv # what the columns actually look like
On Windows PowerShell:
Get-Item big.csv | Select-Object Length
Get-Content big.csv -ReadCount 1000 | Measure-Object -Line
Get-Content big.csv -TotalCount 5
That head matters more than it looks. Half of "corrupted" CSVs are files
delimited with semicolons instead of commas (the standard in much of Europe)
or files with a byte-order mark glued to the first column name. You want to know
that before you blame the size.
Pick your route
| Situation | Best tool |
|---|---|
| Look inside, count things, run a query | DuckDB |
| Must stay in Excel, must make a pivot table | Power Query + Data Model |
| Need it in chunks a spreadsheet can hold | split, or csvkit |
| Repeated analysis, joins across files | SQLite or DuckDB |
| Just need to read one column's values | csvcut, or a large-file text editor |
| The file is on your phone | A CSV app built for large files |
| Need to edit rows and save it back | CSV Editor, or a desktop CSV app |
On a desktop
DuckDB, the 2026 answer
If you take one thing from this guide, take this one. DuckDB is a free single-file database that reads CSV directly, without an import step, and it is absurdly fast at it.
Install it (brew install duckdb, winget install DuckDB.cli, or a download
from duckdb.org), then:
duckdb -c "SELECT * FROM 'big.csv' LIMIT 20"
duckdb -c "SELECT count(*) FROM 'big.csv'"
duckdb -c "DESCRIBE SELECT * FROM 'big.csv'"
That third one gives you every column and the type it inferred, usually the fastest way to understand an unfamiliar export. From there it is just SQL:
duckdb -c "SELECT region, sum(amount) AS total
FROM 'big.csv'
GROUP BY region
ORDER BY total DESC"
And when you want a smaller file back out, one that Excel will open:
duckdb -c "COPY (SELECT * FROM 'big.csv' WHERE year = 2026)
TO 'subset.csv' (HEADER, DELIMITER ',')"
It never loads the whole file into memory, so file size stops being the question. The catch is that you have to be comfortable writing SQL, and it is a terminal tool.
Power Query, when you have to stay in Excel
Excel can handle far more than a million rows, as long as the rows never touch a worksheet. That is what Power Query and the Data Model are for.
In Excel: Data → Get Data → From File → From Text/CSV. In the preview window that appears, do not press Load. Press the arrow next to it, choose Load To…, then pick Only Create Connection and tick Add this data to the Data Model.
The rows now live in Excel's columnar engine instead of the grid, where the 1,048,576 limit doesn't apply. You can build PivotTables and charts against it normally. What you cannot do is scroll through the raw rows, which is usually fine, because scrolling through 4 million rows was never the goal.
Split it into pieces
Sometimes you need spreadsheet-shaped chunks. On macOS or Linux:
split -l 500000 big.csv chunk_
One caveat that catches people: only the first chunk gets the header row. To paste it onto the others:
head -1 big.csv > header.txt
for f in chunk_*; do cat header.txt "$f" > "with_header_$f"; done
csvkit does this properly, and much else.
csvcut -c 1,4 big.csv pulls specific columns, csvgrep -c status -m failed big.csv filters rows, and csvstat big.csv summarises every column. It is
slower than DuckDB on very large files, but it understands quoting and embedded
newlines, which naive shell tools do not.
SQLite, for repeat visits
If you will come back to this file more than twice, or need to join it against another one, load it once:
sqlite3 data.db
.mode csv
.import big.csv sales
.headers on
SELECT count(*) FROM sales;
Everything after that is instant. The trade-off against DuckDB is that SQLite imports everything as text unless you define the table yourself first.
Text editors, with caveats
If you only need to look at raw lines, a large-file-capable editor is the least ceremony:
- EmEditor (Windows) is built for this specifically and opens multi-gigabyte files comfortably. Paid, with a trial.
- Sublime Text handles large files far better than most editors.
- BBEdit (macOS) has no hard file-size limit in its editing engine.
- VS Code will fight you above roughly 50MB and disables many features.
- Notepad will attempt to load the entire file into memory and take the machine down with it. Notepad++ is fine; plain Notepad is not.
Google Sheets and other cloud spreadsheets
Google Sheets caps out at 10 million cells per spreadsheet. That sounds generous, but cells are rows × columns: a 30-column export hits the ceiling at about 330,000 rows. It also has to upload the entire file first. For a big CSV this is usually the slowest route, not the easiest one. Apple Numbers is stricter still, at 1,000,000 rows and 1,000 columns.
When the file is on your phone
This is the case none of the above covers, and it is more common than the desktop-shaped advice on the internet suggests: the export is attached to an email, you are not at your desk, and you need to know what is in it now. There is no terminal, no Power Query, and the built-in file preview will show you the first screen of raw text and stop.
The fix is an app that treats the file size as the starting requirement rather than an edge case.
Opens the whole file, then lets you interrogate it: SQL queries, visual filters, charts, an AI assistant you can ask in plain language, and PDF export.
What it doesThat covers reading. Changing rows and saving the file back is a different job, and the thing to watch for is the truncation problem from earlier: a mobile editor that quietly loaded part of your file will quietly write part of it back.
Spreadsheet-style editing on a 500,000-row file: Excel-style sort and filter, formula columns, undo and redo, and every row preserved when you save, including in the free version.
What it doesFour things not to do
- Don't open it in plain Notepad. It loads the whole file into memory with no streaming and will hang the machine on anything large.
- Don't email the file to yourself to "try on the other computer". Most mail servers cap attachments around 25MB, and the ones that don't will re-encode it.
- Don't save over the original. Work on a copy, always. This is the single habit that turns a truncation accident into a non-event.
- Don't trust a row count you haven't checked. Run
wc -l, orSELECT count(*), and compare it against whatever your tool is showing you. If they disagree, the tool is lying to you.