You buy a 1 TB drive and your computer reports about 931 GB. Nothing is broken and nobody cheated you — two different definitions of "a megabyte" are quietly fighting, and one of them rounds down.
Buy a "1 TB" drive, plug it in, and your computer says it holds about 931 GB. Buy a "16 GB" phone and a chunk is gone before you install anything. It looks like rounding, or marketing sleight of hand, and people have argued about it for decades. The truth is duller and more interesting: there are two different definitions of what a "megabyte" means, they differ by a compounding percentage, and a set of units exists specifically to tell them apart — units most people have never heard of.
Two definitions of the same word
The prefixes kilo, mega, and giga come from the metric system, where they mean exactly 1000, 1,000,000, and 1,000,000,000 — powers of ten. But computers are binary, and it was long convenient to use the nearest power of two: 1024 instead of 1000, because 1024 (2¹⁰) is a round number in binary. So "kilobyte" came to mean 1024 bytes in some contexts and exactly 1000 in others. Same word, two values — and the gap compounds at every step up the ladder.
The units that fix it
To end the ambiguity, a separate set of binary prefixes was standardised. Wikipedia:
"A binary prefix is a unit prefix that indicates a multiple of a unit of measurement by an integer power of two. The most commonly used binary prefixes are kibi (symbol Ki, meaning 2¹⁰ = 1024), mebi (Mi, 2²⁰ = 1048576), and gibi (Gi, 2³⁰ = 1073741824)."
— Wikipedia, "Binary prefix" (CC BY-SA 4.0)
So 1 MB = 1,000,000 bytes (decimal), while 1 MiB = 1,048,576 bytes (binary, "mebibyte"). Kibibyte, mebibyte, gibibyte — the "-bi-" marks the power-of-two version. Precise, unambiguous, and almost nobody uses them in everyday speech, which is why the confusion persists.
Where the missing space goes
Now the drive mystery solves itself. Storage manufacturers advertise in decimal units: a "1 TB" drive holds 1,000,000,000,000 bytes exactly. But many operating systems report size in binary units while still labelling them "GB" — so they take those trillion bytes and divide by 1024 three times, getting about 931. The bytes are all there; the drive isn't lying and neither is the OS. They're just using two different definitions of "giga" and only one of them is showing its work. The discrepancy is about 7% at the gigabyte level and grows as the numbers get bigger, which is why a big drive seems to "lose" more.
The place it actually bites: networks vs storage
Beyond drive labels, the split causes real calculation errors when two fields disagree. Networking almost always uses decimal (a "100 Mbps" link is 100,000,000 bits per second) — and note bits, not bytes, an eightfold difference on top. Storage and memory lean binary. So working out "how long to download this file over this connection" mixes a binary file size with a decimal, bit-based transfer rate, and a naive calculation can be off by 10–15% before you even account for overhead. When a size and a rate come from different worlds, convert them to the same definition and the same unit before you divide.
RAM is the holdout
One place still uses the binary definition with the decimal name, and it's not going away: RAM. When you buy a "16 GB" stick of memory, you genuinely get 16 × 1,073,741,824 bytes — the binary number — because RAM is manufactured in powers of two (each address line doubles the capacity). So "16 GB of RAM" is actually 16 GiB, about 17.18 billion bytes, labelled with the decimal prefix. This is the opposite direction of the drive problem: your RAM is slightly more than the decimal name suggests. The industry hasn't adopted the "GiB" label for RAM packaging, so the ambiguity survives on the one component where the binary definition is physically correct.
Filesystem overhead makes it worse
Even after the 1000-vs-1024 gap is accounted for, your "available" space is still less than the byte count implies. Every filesystem — NTFS, APFS, ext4 — reserves space for its own bookkeeping: allocation tables, journals, metadata, and usually a small percentage held back for the root user or for preventing fragmentation. On a freshly-formatted 1 TB drive, you might see 920 GiB reported, but only 910 GiB actually available to write to. The missing slice isn't the 1000-vs-1024 problem — it's real overhead from the filesystem doing its job. So the total "loss" a user sees is the compound of two separate effects: the unit mislabelling and the filesystem's own tax.
Why the confusion persists
The IEC binary prefixes (KiB, MiB, GiB) were standardised in 1998 — nearly three decades ago — and adoption is still patchy. Most Linux distributions now display sizes in GiB (and label them correctly), but Windows still shows binary values labelled as "GB," and macOS switched to decimal values labelled as "GB" starting with Snow Leopard. So three major operating systems use the same two-letter abbreviation to mean three different things. Until one convention wins everywhere — or until people just learn the gap — "my drive is smaller than the box says" will keep being one of computing's most common complaints.
Convert with the definition in view
The cure is to be explicit about which definition you're using. A file size converter lets you move between bytes, KB/MB/GB and KiB/MiB/GiB so you can see the exact gap — 1 GB versus 1 GiB is not a rounding error, it's 1,000,000,000 versus 1,073,741,824 bytes. A number base converter shows why 1024 is the "round" number in the first place (it's 2¹⁰), which is the whole origin of the binary convention. And for the broader habit of never dividing two numbers in different units, a unit converter keeps you honest. Your drive isn't smaller than promised — it's just being measured with a different ruler than the one on the box.
← All articles