📐 CSV Fundamentals · 7 min read
How Many Columns Can a CSV File Have?
A 3,000-column export opens fine on one machine and dies on another, and the file itself is identical in both cases. Nothing about the CSV changed. What changed is the program on the other end, which is where every column limit actually lives.
Quick answer
A CSV file has no column limit in the format. RFC 4180 defines a record as fields separated by commas and says each line should hold the same number of fields, but it never specifies a maximum. Every ceiling you meet is set by a reader: 16,384 columns in an Excel worksheet grid, 131,072 bytes per field in Python's csv module by default, or your own memory, which is what breaks first on wide files. In our tests a streaming parser read a 10,000,000-column row in 0.45 seconds, while a full 30,000-row by 3,000-column table needed 6,273 MB of RAM to load at once.
The format says nothing about how many columns
RFC 4180 is short and, on this question, silent. Section 2 defines a record as field *(COMMA field), and the accompanying text says that within each record there may be one or more fields separated by commas, and that each line should contain the same number of fields throughout the file. There is no count in it, and the same document admits why: it describes the format that most implementations seem to follow, in a file where no formal specification existed.
The MIME registration in the same RFC lists the optional parameters as charset and header. No column count, no row count, no size. So when a tool refuses your file for having too many columns, it is quoting its own limit, and it is worth finding out which one.
What we measured: a streaming reader on very wide rows
We wrote single-row CSVs of increasing width and read them back with a streaming parser (Python's csv.reader, which follows RFC 4180 quoting rules) on a machine with 4 vCPUs and 15 GB of RAM, on 2026-09-24.
| Columns in one row | Result | Fields parsed | Time | Row size |
|---|---|---|---|---|
| 1,000 | parsed | 1,000 | 0.00 s | 0.002 MB |
| 100,000 | parsed | 100,000 | 0.00 s | 0.2 MB |
| 1,000,000 | parsed | 1,000,000 | 0.03 s | 2.0 MB |
| 4,000,000 | parsed | 4,000,000 | 0.16 s | 8.0 MB |
| 10,000,000 | parsed | 10,000,000 | 0.45 s | 20.0 MB |
Ten million columns came back in under half a second. Column count on its own is not what breaks a parser, and a file that refuses to open is refusing for a different reason than you think. The useful number is not the column count but the total number of cells, which is what the next measurement shows.
What we measured: a realistic wide table
We generated a 30,000-row by 3,000-column CSV, the shape a wide monthly export takes, with unique numbers in every cell: 90,003,000 cells, 761.9 MB on disk.
| How it was read | Cells handled | Time | Peak memory |
|---|---|---|---|
| Row by row (streaming) | 90,003,000 | 7.28 s | 281 MB |
| Whole table held in memory | 90,003,000 | 16.82 s | 6,273 MB |
The same file, read two ways, is the difference between using a fifth of a gigabyte and using six. Every browser-based CSV tool that parses in the tab you are looking at is doing the second thing, which is why a file of this shape is where those tools start failing.
We pushed the second method to find the trend, since the interesting part is the rate rather than the single figure:
| Rows | Cells | File on disk | Time to load | Peak memory | Bytes per cell |
|---|---|---|---|---|---|
| 1,000 | 3,003,000 | 21.8 MB | 0.36 s | 174 MB | 60.9 |
| 4,000 | 12,003,000 | 92.4 MB | 1.60 s | 694 MB | 60.6 |
| 8,000 | 24,003,000 | 195.4 MB | 3.15 s | 1,528 MB | 66.8 |
| 16,000 | 48,003,000 | 401.4 MB | 6.66 s | 3,198 MB | 69.9 |
| 24,000 | 72,003,000 | 607.4 MB | 12.96 s | 4,868 MB | 70.9 |
Stay between 59 and 71 bytes per cell and the arithmetic does the rest. A 500,000-row export with 300 columns is 150,000,000 cells, which lands near 10 GB and will not fit on a laptop even though the CSV on disk is under 2 GB. Rows times columns is the number that decides whether a file opens, not either one alone. That is also why the row-limit advice you find elsewhere does not help here: a file can be comfortably inside every row ceiling and still be unopenable.
Where the limits actually sit
Once you stop expecting a limit in the file, the practical question becomes which reader is refusing you. These are the four that show up in most reports.
| Layer | Limit | What you see |
|---|---|---|
| CSV format (RFC 4180) | none stated | nothing: the file is fine |
| Excel worksheet grid | 16,384 columns by 1,048,576 rows | columns past XFD have nowhere to land; a cell holds at most 32,767 characters |
| Streaming parsers (e.g. Python's csv) | 131,072 bytes per field by default | field larger than field limit (131072), measured on a 140,000-byte field |
| Your machine | about 60 to 71 bytes per cell | the tab or the process dies with no error message at all |
The 16,384-column and 1,048,576-row figures, and the 32,767-character cell ceiling, are from Microsoft's Excel specifications and limits page. On the same page Microsoft notes that 32-bit Excel works inside 2 GB of virtual address space shared by Excel, the workbook and any add-ins, and that the 64-bit build imposes no hard file size limit and is bounded only by available memory and system resources. That is the same shape of limit we measured from the other side, one layer lower.
How to open a file that is too wide
- Check the cell count before you check anything else. Rows times columns. If that number is in the tens of millions, plan for the memory rather than for the error message.
- Read it row by row if you can. Streaming kept our 90-million-cell file at 281 MB instead of 6,273 MB, and most languages and databases offer a streaming path for exactly this reason.
- Split by columns, not only by rows. Splitting by rows is what every CSV splitter does and it solves the grid limit, not the memory problem, because each part still has all the columns. If the width is the issue, cut the file into two sets of columns that share an ID column, and join them again in the tool that needs them.
- Reshape wide into long if the columns are repeating. One column per month or per sensor becomes one date column and one value column, by the same data in fewer cells, and the file stops growing by a column every period.
With a file like that in hand, the CSV analyzer will show you the header row, the field count per row, and whether any row disagrees with the header about how wide the file is. If the file also opens with everything in a single column or with long numbers rewritten as 1.23E+15, those come from the same reader making guesses and are worth fixing in the same pass.
Frequently asked questions
How many columns can a CSV file have?
The CSV format itself sets no column count. RFC 4180 defines a record as one or more fields separated by commas, and it states that each line should contain the same number of fields throughout the file, but it never names a maximum number of fields. Any column ceiling you hit comes from the program reading the file, not from the file format. In our test a streaming parser read a single row of 10,000,000 columns in 0.45 seconds.
Can a CSV have more than 1,000 columns?
Yes. We wrote and read a CSV with 3,000 columns and 30,000 rows, which is 90,003,000 cells and 761.9 MB on disk, and a streaming reader processed every row in 7.28 seconds. The same file became slow only when we loaded the whole table into memory at once, which took 16.82 seconds and 6,273 MB of peak memory on a machine with 15 GB of RAM. Column count is rarely the thing that breaks first; total cell count is.
What is Excel's column limit for a CSV?
Excel's worksheet grid holds 1,048,576 rows by 16,384 columns, so columns beyond the 16,384th have nowhere to land when a CSV opens in a worksheet. Microsoft's specifications page also notes that a cell can contain at most 32,767 characters. The file keeps all of its columns on disk, which is why a 40,000-column export can look complete in a text editor and truncated in Excel.
Is there a limit on the size of a single field?
Not in the format, but several readers impose one. Python's csv module defaults field_size_limit to 131,072 bytes, and a quoted 140,000-byte field raised "field larger than field limit (131072)" in our test. Raising the limit with csv.field_size_limit() and re-running let the same reader accept a 5,000,000-byte field in 0.10 seconds. Databases and cloud warehouse loaders often default to a max field length as well, so check the loader before blaming the file.
Why does a wide CSV make my computer run out of memory?
Because a program that reads the whole table at once stores every cell as a separate object in memory. In our measurements the peak memory grew from 174 MB for 3,003,000 cells to 4,868 MB for 72,003,000 cells, between 59 and 71 bytes per cell, so a table with tens of millions of cells needs gigabytes of RAM even though the file on disk is far smaller. Reading row by row keeps memory flat, because each row is discarded before the next one is parsed.
How do I know whether my wide file will load?
Multiply rows by columns to get the cell count, then count on roughly 60 to 70 bytes of memory per cell for a loader that holds the whole table. A 500,000-row export with 300 columns is 150,000,000 cells, which is on the order of 10 GB, and that will fail on most laptops regardless of how well formed the CSV is. If the number is large, split the file by columns before it reaches the tool rather than after it crashes.
Which is more likely to break a CSV, rows or columns?
Rows, for the tools people actually use. A streaming parser stays fast on enormous row counts because each row is handled on its own, and long files (rather than wide ones) are what run into per-file upload caps, memory ceilings in spreadsheet programs, and the row grid limit of 1,048,576 that Excel enforces. Wide files break in a different place: memory, because the cell count multiplies rows by columns instead of adding to it.
Does a wide CSV mean the export was done wrong?
Usually it means the data was stored in a wide layout rather than a long one. A monthly report with one column per day becomes 365 columns a year later and 730 the year after, and it keeps growing. Reshaping those columns into one date column and one value column keeps the cell count the same but removes the width problem, and it is the change that survives the next year of data.
Tools mentioned in this guide
Measuring a wide file and splitting it are both short scripts. These cover the cases where you would rather not write one:
- OpenCode Go — generating a 30,000 by 3,000 table and reading it two ways is a few lines, and re-running it on your own export tells you which limit you are about to hit before the tool does. Try OpenCode Go
- Stack AI — if wide exports arrive on a schedule, a workflow can split or reshape them on arrival, so an export that doubles in width fails the workflow instead of landing in the report. Try Stack AI
- Softr — when the same wide sheet is re-sent every month, holding the records in a no-code app once removes the round trip through a text file altogether. Try Softr
Some links above are affiliate links — if you buy through them we may earn a commission at no extra cost to you. OpenCode Go uses our referral link; the other two currently point to each vendor's official page until our tracking links are approved.
See How Wide Your File Really Is
Paste the first rows and check the field count per row before the tool refuses the whole file.
The record, field and header wording is from RFC 4180, section 2, and the absence of a maximum field count from the same section and its MIME registration in section 3. The 16,384-column, 1,048,576-row, 32,767-character and 2 GB virtual address space figures are from Microsoft's Excel specifications and limits page, retrieved on 2026-09-24. Every timing and memory figure in the two measurement tables comes from scripts we wrote and ran on 2026-09-24 on a 4-vCPU, 15 GB machine with Python 3.13.5, using the standard librarycsv module; the raw output is kept with our other measurement records.
Related reading
Data Cleaning — other guides that pair well with this one.
Browse all guides in the NoCodeCSV blog.