You buy a drive with a bold 1 TB label, connect it to your computer, open its properties — and see 931 GB. Nearly 70 gigabytes seem to have evaporated before you saved a single file. The instinct is always the same: the drive is faulty, or the manufacturer lied. In reality, not one byte went missing. What you are looking at is the sum of three overlapping effects: two different number systems, a hidden reserve baked into the memory architecture, and the price the operating system pays just to make the drive usable.
Two systems, one abbreviation
The heart of the matter is a disagreement over how many bytes fit in a "gigabyte". Storage makers count in decimal, following the SI system: 1 kB = 1000 bytes, and every further prefix is the next power of a thousand. A "1 TB" drive therefore holds exactly 1,000,000,000,000 bytes — an honest, precise figure.
The trouble is that computers count in binary. In their world the natural "round" number is not 1000 but 2¹⁰ = 1024. Historically these two values sit so close together that early computing jargon began calling 1024 bytes a "kilobyte", borrowing the metric prefix for a binary quantity. At the kilobyte level the mismatch was a trivial 2.4% and bothered no one. The catch is that with every higher order of magnitude the error multiplies.
To tidy up the naming, the International Electrotechnical Commission (IEC) introduced separate binary prefixes in 1998: the kibibyte (KiB), mebibyte (MiB), gibibyte (GiB) and tebibyte (TiB) — precisely for the 1024-based values. The standard has existed for a quarter of a century, yet many operating systems still ignore it, dividing by 1024 while labelling the result with the decimal "GB".
| Order | Decimal (SI) | Binary (IEC) | How much the number "shrinks" |
|---|---|---|---|
| kilo | 1,000 B (kB) | 1,024 B (KiB) | 2.34% |
| mega | 1,000,000 B (MB) | 1,048,576 B (MiB) | 4.63% |
| giga | 1,000,000,000 B (GB) | 1,073,741,824 B (GiB) | 6.87% |
| tera | 1,000,000,000,000 B (TB) | 1,099,511,627,776 B (TiB) | 9.05% |
| peta | 10¹⁵ B (PB) | 1,125,899,906,842,624 B (PiB) | 11.18% |
That is where our 931 GB comes from. The drive holds 10¹² bytes; the system divides them by 1,073,741,824 (a gibibyte) and gets 931.32 — but prints the abbreviation "GB" instead of "GiB". The physical byte count never changes; only the number we divide it by does. The bigger the drive, the bigger the apparent loss: at the petabyte scale the gap already exceeds 11%.
This is not a new problem. In the DOS era a single FAT partition topped out at 2 GB, and early BIOSes could only "see" 504 MB or 528 MB of a disk — all because hardware and software measured capacity in incompatible units.
Windows counts differently than macOS
So how much "vanishes" depends not on the drive but on who is showing you the number.
Windows divides by successive powers of 1024, but consistently labels the result with decimal abbreviations (KB, MB, GB, TB). It is the worst of both worlds: a binary figure under a decimal label — and it is Windows that frightens the user with "931 GB".
macOS went the other way. Since Snow Leopard (10.6) Apple reports capacity in pure decimal, in line with SI. Finder shows that same 10¹²-byte drive simply as 1.0 TB — exactly what the box says.
Linux is inconsistent: the Debian installer and GNOME Disks count decimally (SI), while partitioning tools such as GParted honestly use IEC units and label them "MiB" and "GiB". One capacity, three readings — depending on the authors' philosophy.
| Label | Actual bytes | macOS / Linux (SI) | Windows (binary) |
|---|---|---|---|
| 120 GB | 120,000,000,000 | 120 GB | ~111.8 GB |
| 500 GB | 500,000,000,000 | 500 GB | ~465.7 GB |
| 1 TB | 1,000,000,000,000 | 1.0 TB | ~931.3 GB |
| 2 TB | 2,000,000,000,000 | 2.0 TB | ~1862.6 GB |
| 4 TB | 4,000,000,000,000 | 4.0 TB | ~3.64 TB |
| 20 TB | 20,000,000,000,000 | 20.0 TB | ~18.2 TB |
Space you cannot see: over-provisioning
On SSDs a second, entirely different mechanism comes into play — this time not cosmetic but physical. NAND flash has an awkward property: you cannot overwrite data in place. Reads and writes happen in small pages (usually 4 KB), but erasing is only possible in much larger blocks (say, 128 pages at a time). To overwrite one file, the controller must move every still-active page out of the block, erase the whole block, and only then write.
To keep that shuffling smooth and to wear the cells evenly, engineers reserve extra space that is invisible to both the operating system and the user. This is over-provisioning (OP), the controller's working buffer, where garbage collection and wear levelling run in the background.
The most interesting part is where its baseline level comes from. Take a drive whose NAND chips physically hold 128 GiB, that is 128 × 2³⁰ = 137.44 billion bytes. The manufacturer sells it as a "128 GB" model in the decimal sense (128 × 10⁹ bytes). The surplus — about 9.4 GB, or exactly 7.37% — does not disappear. The controller keeps it for itself. In other words, the very gap between the binary and decimal definitions of a gigabyte becomes free reserve memory. In enterprise drives that reservation is raised deliberately, up to 28%, buying higher IOPS stability and longer endurance (measured as TBW) at the cost of visible capacity.
It is worth adding that cheaper designs without their own DRAM cache (so-called DRAMless) must keep the address map in the flash itself, which slows writes and wears the cells faster — but that is a topic for another article.
The formatting tax
The final instalment of the "loss" is charged the moment the operating system so much as picks the drive up. Before you save your first file, the drive needs a partition table and a file system — and both take up space for their own bookkeeping.
A modern Windows 11 install on a GPT system disk creates several partitions that will never hold your files: the bootable EFI partition (ESP, typically 100–300 MB), a 16 MB Microsoft Reserved Partition, and the WinRE recovery partition (a recommended 990 MB or so, to fit the ever-growing update images). Simply preparing such a disk can swallow over 1 GB before you install anything at all.
On top of that sits the overhead of the file system itself, which depends on its design:
| File system | Max file size | Max partition | Nature of overhead |
|---|---|---|---|
| FAT32 | 4 GB | 2 TB (up to ~16 TB) | minimal; no journaling — prone to corruption on power loss |
| exFAT | 16 EB | 128 PB | small; optimised for flash, no journaling or permissions |
| NTFS | 8 PB | 8 PB | transactional journaling, a dynamically growing MFT, crash-resilient |
| ext4 | 16 TB | 1 EB | pre-allocated inode table + a default 5% of blocks reserved for root |
Each of these pays for something different. NTFS reserves room for its transaction log and Master File Table. Linux's ext4 builds a full inode table the moment you format and, by default, sets aside 5% of capacity "for the administrator". macOS's APFS shares space among the volumes in a container, which makes "free space" a fluid notion — dependent on snapshots and clones the system releases with a delay.
Gigabytes in court
The decimal-versus-binary discrepancy was settled not in a lab but in a courtroom. Consumers repeatedly argued that advertising capacity in decimal without a clear explanation is an unfair practice.
The turning point was the Western Digital settlement of 2006: buyers of drives (say, an 80 GB unit showing about 74.5 GB in Windows — 7% less) received free backup software, and the company was required to state plainly on its packaging that 1 GB = 1,000,000,000 bytes. Four years later a similar case, Cho v. Seagate, ended in a settlement of around $5.4 million — customers from 2001–2007 could recover 5% of a drive's price. Together these two cases firmly established the duty to report capacity consistently.
The issue resurfaced on mobile devices: the 2014 Orshan v. Apple lawsuit alleged that after the iOS 8 update the operating system alone occupied over 3 GB on a 16 GB iPhone — up to 23% of the advertised memory — nudging users toward paid iCloud storage. The litigation dragged on for years, showing that capacity transparency is still a live question.
A separate thread is about quality, not numbers. Manufacturers, Western Digital among them, quietly slipped SMR recording technology (overlapping tracks, like roof shingles) into ordinary hard drives, dramatically slowing random writes — without changing the labelling. That triggered the class action Brown v. Western Digital around the WD Red series. The lesson for the buyer is the same: the number on the box does not tell the whole truth about what you get.
Nothing disappears
The "missing gigabytes" are neither a defect nor a scam, but the price we pay for the fact that memory physics and software logic speak different languages. Part of the loss is purely apparent — the same set of bytes divided by 1024 instead of 1000. The rest is real, but deliberate: over-provisioning buys SSD endurance, and system partitions and journaling buy resilience against failure. None of these reserves is waste — they are the cost of data integrity.
The real fix is not to redesign drives but to build honest interfaces. If every operating system did what macOS does — showing either honest SI or honest "GiB" — all this confusion and half the lawsuits would simply vanish. Until that happens, remember one thing: your 1 TB drive holds exactly as many bytes as the label promises. Windows just counts them its own way.
Further reading
- Seagate, Storage capacity measurement standards — the manufacturer's official explanation of why the label differs from the system reading.
- Kingston, Understanding SSD Over-provisioning (OP) — how and why the controller reserves hidden flash space.
- Wikipedia, Binary prefix — the history of binary prefixes and the 1998 IEC standard.
- ClassAction.org, Brown v. Western Digital Corporation (4:20-cv-08102) — the court filing on the hidden SMR technology.