Skip to content
OneKitly

A Cell of Three Spaces Counts as Empty, and That Is the Point

Published 9/14/2026 · 4 min read · File tools

Daniel Okonkwo

Daniel OkonkwoFront-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 3 sources

View profile
In short

A cell is treated as blank here if it holds nothing, holds a null, or holds only whitespace — so a row of three spaces, an empty string and a null is an empty row and goes. That definition is doing real work: exported and copy-pasted data is full of cells that display as nothing and contain a space, and a test that only accepted true emptiness would leave every one of them behind. Measured on a five-row sheet holding a, two spaces, an empty string, a null and b, three rows were removed and two kept. The column pass works the same way down each column instead of across each row, and it looks at the width of the widest row rather than the header — a sheet whose header is shorter than its body used to lose everything past the header's last cell while reporting that nothing had been removed. Both tools report their count, and the count is what you check against your own reading of the file.

Whitespace is the whole reason these tools exist. A row of blanks looks empty, is not empty to a strict test, and quietly survives every filter you apply after it.

Where the blank rows come from

Reports write them on purpose. A monthly export that puts a blank line between sections, a system that pads every page to a fixed number of rows, a print layout carried into the data — all of them produce a file that reads well and computes badly, because a blank row inside a range stops a fill, breaks a table's detection of its own extent and gets counted by anything that counts rows. The same goes for trailing blanks: a sheet whose last used cell is far below its last real value has a used range full of nothing, which is why a small table can produce a file of several megabytes.

The column pass, and the bug it used to have

Removing empty columns needs a width to work with, and the obvious choice — the length of the first row — is wrong for any sheet whose header is shorter than its data. That happens whenever an export leaves a column unlabelled, which is common enough. Taking the header's width silently deleted every column past its end, and the count of removed columns still said zero: data gone, and the report insisting nothing had happened. The width is now the longest row in the sheet, so a header of two over a body of three keeps all three and pads the header with an empty cell. It is worth knowing this existed, because a file cleaned before the fix may be short a column and will not say so.

What counts as blank, cell by cell
Cell contentsBlank?
nothing at allYes
an empty stringYes
three spacesYes
a tab characterYes
the number zeroNo — it is data
the text "0"No
a formula returning ""Yes, once converted to values
Remove empty rowsStrip every row whose cells are all blank, closing the gaps left by an export. Works with Excel (XLSX, XLS, XLSM, XLSB), OpenDocument (ODS), Apple Numbers, CSV and TSV.Try the tool

Frequently asked questions

Will it remove a row where only one cell has a value?
No. A row goes only when every one of its cells is blank. One value anywhere in the row keeps it, which is what you want for a subtotal line or a row where a single flag is set. If you need to drop rows that are missing a specific column, that is a filter and belongs in the spreadsheet, not here — the tool has no notion of which column matters to you.
Does it touch merged cells or formatting?
The result is written as a fresh sheet of values, so merged cells, colours, column widths and conditional formatting do not survive. That is a real cost and worth weighing: if the formatting matters, do the cleaning in the spreadsheet itself. If what you have is an export on its way into another system, the formatting was never going to survive that trip anyway.
In what order should I run the cleaners?
Merge, then deduplicate, then empty rows, then empty columns. Deduplicating before merging misses the duplicates that only appear once the files are together, and removing empty rows before deduplicating means the duplicate pass has fewer rows to compare but sees exactly the same duplicates — so the order between those two only affects speed. Columns last, because removing rows can leave a column empty that was not before.

Articles you may find interesting

All guides
ExplainerThe Number 1 and the Text "1" Are Not DuplicatesDeduplication compares whole rows exactly, cell type included. Five identical-looking rows came out as three, because one held a number, one a string and one a string with a leading space.How-toMerging Workbooks: One Sheet Each, or One Table for AllTwelve monthly reports can become twelve tabs or one table of twelve months. Only the second can be sorted and summed in one go — and it is the one where the header rows need handling.ExplainerThe Workbook with Twenty-Three Formulas That Reported NoneA cell can hold a formula and no cached result. A reader that skips empty cells throws the formula away with them — and says the file has none. One parsing option separates the two cases.How-toOne File per Tab, and What a Split Leaves BehindSplitting a workbook writes one .xlsx per sheet, named after the tab. It carries the values across and not the formulas — which is the right default when the point is to send one department its own tab.ExplainerThe .ods File That Is Valid, and That Your Reader RefusesOpenDocument makes styles.xml optional. Several readers demand it and reject the whole document without it — "Cannot find file styles.xml in zip" on a file that is not broken.ExplainerConverting Formulas to Values Keeps the Cached Answer, Not the CalculationA spreadsheet file stores both the formula and the last answer Excel computed. Stripping the formula leaves the stored answer — and leaves a blank wherever the file never carried one.

Related tools

Sources

Spotted a mistake in this article?