How Much Data Fits in One Sheet—and What to Do Before You Publish It

Google announced that Google Sheets is increasing its capacity from up to 10 million to up to 20 million cells per spreadsheet. The change provides more headroom, but it does not mean 20 million rows or guarantee that every workbook will remain responsive near the ceiling. During the September 2026 phased rollout, some accounts may still encounter the former limit. Before publishing a large dataset, calculate its workbook-wide cell budget, remove unnecessary grid space, and create a curated, nonsensitive reader-facing export. Google’s September 10 announcement details the new limit and rollout.

The short answer: Google Sheets is rolling out support for up to 20 million cells

On September 10, 2026, Google announced that the Google Sheets ceiling was increasing from up to 10 million to up to 20 million cells per spreadsheet. The expanded capacity applies to new and existing spreadsheets as well as imported XLSX and CSV files. No administrator setup is required.

Status as of September 20, 2026:

• Rapid Release: Rollout began September 10 and could take up to 15 days.
• Scheduled Release: Rollout was due to begin September 28 and could also take up to 15 days.

Scheduled Release deployment therefore had not begun as of September 20. Even an eligible account could temporarily encounter the former ceiling while deployment remained in progress. These dates and rollout windows come from Google’s general-availability announcement.

There was also a documentation mismatch. Google Drive Help still listed a limit of 10 million cells when checked during September 2026, while the newer Workspace announcement specified 20 million. The sources do not resolve this discrepancy, so it is best understood as possible rollout or documentation lag—not proof that either figure applied universally at that moment. Google Drive Help displayed the older limit.

The September release also differs from the earlier program announced on April 22. In April, 20-million-cell capacity was an allowlisted beta: organizations had to register and wait for confirmation. September marked the beginning of a phased general rollout with no administrator action required. Google also included the doubled limit in its September 11 Workspace recap.

Twenty million cells is a workbook budget, not 20 million rows

InfoLobby reports that the limit is shared across the spreadsheet file’s tabs and includes allocated grid cells, not only cells containing values. This counting model is secondary reporting rather than a formula published in Google’s September announcement.

Under that reported model:

Workbook cells = the sum of rows × columns for every tab

It is not a separate 20-million-cell allowance for each tab. Empty-looking rows and columns may still consume capacity if they remain part of the allocated grid.

For a simple one-tab table:

Theoretical rows available = remaining cell budget ÷ number of columns

The figures below are theoretical. They assume no cells are allocated on other tabs and that one table uses the entire budget. The calculations follow the workbook-wide counting model described by InfoLobby.

Dataset width	Former 10M limit	New 20M limit
20 columns	500,000 theoretical rows	1,000,000 theoretical rows
50 columns	200,000 theoretical rows	400,000 theoretical rows
100 columns	100,000 theoretical rows	200,000 theoretical rows

A multi-tab workbook uses the same reported shared budget. For example:

• Tab A: 200,000 rows × 50 columns = 10 million cells
• Tab B: 100,000 rows × 60 columns = 6 million cells
• Reported workbook total: 16 million cells

This estimate applies even if portions of those allocated grids appear blank. For planning, inventory every tab—not just the largest data table. Staging areas, old extracts, lookup tabs, scratch work, and wide reporting tabs can all reduce the theoretical rows available to the primary dataset.

What the higher ceiling covers—and what it does not

The expanded cell capacity covers new spreadsheets, existing spreadsheets, and imported XLSX and CSV files. It does not erase every other restriction associated with spreadsheets, imports, conversion, or Connected Sheets.

Key limits to keep separate

• Spreadsheet capacity: Up to 20 million cells under the new rollout
• Maximum width: 18,278 columns, ending at ZZZ
• Excel conversion: Cells containing more than 50,000 characters are dropped
• Connected Sheets pivot tables: Limited to 200,000 rows

The latter three limits appear in Google Drive Help, which still displayed the older 10-million-cell workbook figure during the September rollout.

The 200,000-row restriction applies specifically to Connected Sheets pivot tables. It is not the row limit for an ordinary spreadsheet, where theoretical row capacity depends on table width and cells allocated elsewhere.

Cell count is also separate from imported-file byte size. Google said it planned to increase byte-size limits for imported spreadsheets, but its announcement supplied neither a new figure nor an implementation date. Do not assume that this separate increase arrived with the 20-million-cell rollout.

Likewise, ordinary spreadsheet capacity should not be conflated with limits governing APIs, import functions, or other Connected Sheets operations. Each applies to a different task.

Why a workbook may still stop at 10 million cells

If a workbook still encounters the former ceiling, use this sequence:

1. Check the date. During September 2026, the rollout could still be underway.
2. Check the account’s release track. Rapid Release deployment began September 10 and could take up to 15 days. Scheduled Release deployment was due to begin September 28 and could also take up to 15 days.
3. Compare the timing with the latest Workspace announcement. A phased release means accounts can behave differently during deployment.
4. Allow for documentation lag. Google Drive Help still displayed 10 million cells during September, adding to the ambiguity.

The rollout dates, deployment windows, and absence of required administrator setup are documented in Google’s September announcement. There is no documented user setting or administrator switch that enables the expanded capacity; it should become available automatically when rollout reaches the account.

Do not deliberately create or import an oversized operational workbook merely to test availability. Use the official rollout schedule and observe normal account behavior instead.

How to reclaim cell capacity before splitting the file

Start by preserving an untouched source copy. Perform cleanup in a working duplicate so that removing grids, tabs, or columns does not destroy records you later discover are necessary.

InfoLobby reports that allocated blank grid space counts toward the workbook budget. Under that model, deleting genuinely unused rows and columns reclaims capacity, while merely clearing their contents does not shrink the allocated grid. This is practical secondary-source guidance, not a counting specification in Google’s September announcement.

A practical cleanup sequence is:

1. Delete unused trailing rows. Remove rows below the actual end of each table.
2. Delete unused trailing columns. Wide tabs can consume substantial capacity even when most columns are empty.
3. Remove obsolete tabs. Old imports, abandoned calculations, and temporary scratch tabs still contribute under the reported counting model.
4. Consolidate redundant staging data. Avoid retaining several complete copies of the same extract in one workbook.
5. Reduce the reader-facing schema. Remove fields unnecessary for analysis or publication while retaining required source records in the private source system.
6. Recalculate the grid budget. Add rows × columns across every remaining tab.

If the cleaned table still exceeds the available budget, archive older periods or divide the data into date- or subject-specific tables. Split according to how readers will use the data rather than cutting it into arbitrary fragments.

Every split should preserve:

• stable record identifiers;
• compatible column names and data types;
• clear coverage dates;
• source and transformation notes;
• version or update information.

A smaller table without provenance may fit technically but be less useful than the original.

Capacity does not guarantee a usable spreadsheet

The 20-million-cell announcement establishes a maximum capacity. It does not demonstrate that every workbook will load, calculate, filter, or support collaboration smoothly near that maximum.

Two files with the same dimensions may behave differently.

In April, Google reported that spreadsheets containing at least 1 million cells could open and become usable up to 30% faster, while filtering and conditional formatting could each be up to 60% faster. These are vendor-reported “up to” improvements, not guarantees for a particular dataset, device, or browser. Google’s April performance announcement defines the scope of those claims.

Choose the storage and publication approach according to the job:

Path	Best fit	Main consideration
Keep one workbook	One coherent task with acceptable real-world behavior	Simplest to maintain, but test it
Split or archive	Readers need distinct periods or subjects	Preserve identifiers and schemas
Use BigQuery with Connected Sheets	Source data is unsuitable for routine spreadsheet storage	Keep query results separate from the source system

Do not treat 20 million cells as a target. Test the finished dataset using the actions readers and editors will actually perform:

• initial loading;
• sorting;
• filtering;
• representative searches;
• common calculations;
• switching between necessary tabs.

If those tasks are consistently awkward, the workbook may be too large or complex for its intended use even if it remains below the formal ceiling.

Prepare a large spreadsheet for safe public publication

An operational workbook is rarely the right public artifact. It may contain calculations, staging tabs, editorial notes, internal identifiers, incomplete records, or fields collected for purposes unrelated to publication.

Create a curated reader-facing export instead. Keep the operational source private and preserve it unchanged for audits and future updates.

Before publishing, check that the export has:

• one clear header row;
• concise, consistent field names;
• consistent data types within each column;
• only the columns readers need;
• stable identifiers where records may be joined or cited;
• source attribution;
• coverage start and end dates;
• an update date;
• notes describing material transformations.

Add a data dictionary for fields that are abbreviated, coded, calculated, or easy to misinterpret. Provenance notes should explain where the data came from, what was excluded, and how the published version differs from the source.

As a matter of TablePage editorial policy, remove personal, confidential, and operational information before upload. Review hidden tabs, rows, and columns as part of that process; if information should not be public, remove it from the publication file rather than relying on its hidden state.

Also consider whether readers need all historical records at once. A documented series of annual or subject-specific tables may be easier to search and reuse than one maximum-size workbook. Keep schemas compatible and provide coverage notes so the collection still functions as a coherent dataset.

TablePage describes its product as a way to turn a finished spreadsheet into a public interactive data page. That publication step should follow cleaning, documentation, and privacy review—not replace them. Do not assume that Google Sheets’ 20-million-cell ceiling is also a TablePage upload limit; verify the publishing service’s current requirements before preparing an upload.

Treat 20 million cells as additional headroom rather than a target. Confirm that rollout has reached the account, calculate the workbook-wide cell budget, remove unnecessary grid space, and keep capacity distinct from import and performance constraints. For public release, preserve the private source and publish a smaller, documented, nonsensitive table designed around what readers actually need to explore.