The Excel row limit is 1,048,576 rows per worksheet, alongside 16,384 columns, in every current version: Microsoft 365, Excel 2021, and everything back to Excel 2007. The number is fixed in the file format itself, so no setting, plan, or registry trick raises it. Below are the hard numbers in one table, what to do when you genuinely have more data than a sheet can hold, and then the more useful question: which limitations of Excel actually slow business teams down. For most teams it is not the row count.
The Excel row limit and the other hard numbers
| Limit | Value |
|---|---|
| Rows per worksheet | 1,048,576 |
| Columns per worksheet | 16,384 (last column is XFD) |
| Characters in a single cell | 32,767 |
| Column width | 255 characters |
| Worksheets per workbook | Limited only by available memory |
| Memory, 32-bit Excel | 2 GB of address space for everything Excel holds open |
The odd-looking numbers are powers of two: the .xlsx format addresses rows with 20 bits (2^20 = 1,048,576) and columns with 14 bits (2^14 = 16,384). That is why the limit is architectural rather than a product decision, and why it has not moved in almost two decades. Microsoft keeps the complete list, down to undo levels and pivot field counts, on its Excel specifications and limits page.
In practice you will feel pain well before row 1,048,576. A sheet with hundreds of thousands of formula rows recalculates slowly, and on 32-bit installations the 2 GB memory ceiling arrives long before the grid runs out. If a workbook is sluggish at 80,000 rows, the row limit is not your problem; formula structure and file size are.
What to do when your data really is bigger than a sheet
Open a CSV with two million rows and Excel loads the first 1,048,576, shows a "not loaded completely" warning, and silently drops the rest. Never analyze a truncated import; the missing rows do not announce themselves. You have two honest options inside Excel:
- Load to the Data Model instead of the grid. Via Get Data (Power Query), choose "Add this data to the Data Model" rather than loading to a worksheet. The Data Model compresses data in memory and holds far more than a million rows, which you then analyze through pivot tables. The grid never displays the raw rows, and it does not need to.
- Move the raw data to a database. When the data outgrows one analyst's machine, or several people need to query it, a database or warehouse is the right container, with Excel querying summaries of it.
Both are real solutions for genuinely large data. But be honest about how often that describes your workbooks. A pricing model, a sales forecast, a project budget: these run to thousands of rows, not millions. Which is why hitting the row limit is rare, while the next set of limitations is hit daily.
The limitations of Excel that actually hold teams back
The limits that cost business teams time are not in Microsoft's specification table. They are limits on people, and they show up the moment a working model meets the rest of the organization.
Only the author can use the model safely. A good workbook encodes real expertise, but its safety rails are conventions: the blue cells are inputs, don't touch column Q, the summary tab assumes you refreshed the data first. Hand it to a colleague and every convention is one mis-click from breaking. So the expert becomes the bottleneck, running every scenario personally.
Sharing means sending everything. An .xlsx file has no partial mode. Whoever receives the file receives every tab, every formula, every hidden sheet, including the ones you would rather keep internal. There is no way to hand someone three input cells and a result.
Collecting input means merging copies. Mail a template to twenty managers and twenty diverging files come back, each pasted into the master by hand. The consolidation work grows with every contributor, and so does the chance of overwriting the wrong version.
There is no access control per range. Sheet protection deters accidents, but it does not create permissions. Anyone with the file can read the logic, and hidden is a display state, not a security boundary.
Notice that adding rows fixes none of this. Neither does migrating to different spreadsheet software, which mostly relocates the same problems.
Separate the roles: Excel as the backend
The fix that preserves the expertise is to split two jobs the workbook currently does at once. Experts keep building and owning the logic in Excel, because no other tool lets a domain specialist express calculation logic as fast. Everyone else gets a purpose-built interface on top of the model: a small app with exactly the inputs and results their job needs, and nothing else. The workbook becomes the engine; the sheet stops being the user interface. We have argued this "Excel as a backend" idea for years, and it is the entire design of airrange.
Concretely: you select the ranges that matter, link them to app controls, and publish a web app that runs the workbook's logic. Colleagues open a link in the browser; they cannot touch column Q because column Q simply is not there. The calculations run in each visitor's browser, so there are no view quotas or calculation limits; an app used ten thousand times stays as fast as one used once. When contributors enter numbers, you review each proposed change inside the Excel add-in and merge the accepted ones back into the master file, which replaces the twenty-copies merge with a controlled queue. And it works with local files as well as Microsoft 365 files, in any Excel version that can run add-ins from the Microsoft store, so the master workbook can stay exactly where it is today. The Excel to web app page shows the flow end to end.
The honest limits of the app-on-top approach
A post about limits owes you the new ones you take on, because they exist too.
Uploading an Excel file into airrange is capped at 1 MB, which sounds small until you remember the target: lean logic, not raw data storage. Bigger workbooks are connected instead of uploaded, as a local file or a Microsoft 365 file, where no upload limit applies. The calculation engine covers the large majority of Excel functions, including modern ones like XLOOKUP, FILTER, LET, and LAMBDA with spilling, but not everything: the FORECAST.ETS family and STOCKHISTORY are unsupported, pivot tables are removed during import, and VBA macros never run in the browser. If your model leans on one of those, you rebuild that piece or precompute it. The practical consequence: test your specific workbook before you commit, which takes minutes on a free account.
Fix the limit you are actually hitting
If you are truly staring at row 1,048,576, use the Data Model or a database; that is what they are for. But if your real symptoms are a bottlenecked expert, workbooks traveling by email, and afternoons lost to merging copies, more rows will not help, and neither will replacing Excel. Keep the model, add an interface. Pick one workbook that too many people touch and turn it into an app; the row limit will be the least interesting limit you left behind.