MB vs MiB — Why Your Storage Never Shows What the Box Says
You buy a 1 TB hard drive. You plug it in, and Windows shows 931 GB. You feel cheated. But nobody lied to you — two different industries have been using the same word to mean two different numbers for decades, and the fallout lands on you every single time you buy a drive.
My first computer had an 80 MB hard drive. I remember the sticker on the box clearly, and I remember the drive showing up as slightly less than that in Windows. I assumed there was something wrong with my machine. My uncle, who was more technical, said "computers round things differently" and moved on. That answer was vague enough to feel satisfying and precise enough to seem credible. It carried me for years.
The actual explanation is both simpler and more irritating than "computers round things differently." It comes down to two industries — hardware manufacturers and software developers — having independently decided that a kilobyte means different things, and neither of them technically being wrong, and nobody ever fixing it properly, and you being stuck with a number on your screen that will never match the number on the box.
The MB vs MiB distinction is the formal attempt to clean this up. It mostly failed in practice. But understanding it explains the hard drive thing, the RAM thing, the internet speed thing, and about a dozen other minor frustrations that computer users treat as an unsolvable mystery.
The Real Problem — Two Definitions, One Word
In the rest of the world, "kilo" means 1,000. A kilogram is 1,000 grams. A kilometre is 1,000 metres. A kilojoule is 1,000 joules. This is the metric system, and it's been consistent for over two centuries. Kilo is always 1,000. Mega is always 1,000,000. Giga is always 1,000,000,000.
Computers work in binary — everything is powers of 2. And 2 to the power of 10 is 1,024. That's close to 1,000, but not 1,000. Early computer engineers needed a word for "1,024 of something" and they borrowed "kilo" because 1,024 is approximately 1,000. It was a convenience shortcut that made rough sense at the time.
So from very early on in computing, "kilobyte" started meaning two different things depending on who was talking. Hardware manufacturers — particularly hard drive makers — used the standard metric definition: 1 KB = 1,000 bytes. But operating systems and programmers largely used the binary definition: 1 KB = 1,024 bytes. Both groups called it a kilobyte. Neither group put a disclaimer on the label.
- 1 KB = 1,000 bytes exactly
- 1 MB = 1,000,000 bytes exactly
- 1 GB = 1,000,000,000 bytes
- 1 TB = 1,000,000,000,000 bytes
- Used by: HDD/SSD manufacturers, USB makers, phone storage specs, network speeds
- Makes drives look bigger on the box
- 1 KB = 1,024 bytes
- 1 MB = 1,048,576 bytes
- 1 GB = 1,073,741,824 bytes
- 1 TB = 1,099,511,627,776 bytes
- Used by: Windows, Linux (traditionally), RAM specs, file sizes in most software
- Makes drives look smaller than the box
The gap looks small at the kilobyte level — 1,000 vs 1,024 is only a 2.4% difference. But the percentage doesn't stay flat. It compounds at every level up. By the time you're at terabytes, the difference between the manufacturer's number and the operating system's number is almost 10%. That's where the 1 TB = 931 GB mystery comes from. It's not rounding. It's a definitional gap that grows with every order of magnitude.
Where 1024 Comes From, and Why It Stuck
Binary is base-2. Everything in a digital computer is ultimately a 1 or a 0. Memory addresses, storage blocks, file system structures — they all work in powers of 2 because that's what the underlying hardware is built around. 2¹ is 2. 2² is 4. 2³ is 8. Keep going: 2¹⁰ is 1,024.
1,024 is the natural unit size for binary systems. Memory chips were designed in blocks of 1,024 bytes because that fits cleanly into binary addressing. A 10-bit memory address can point to exactly 1,024 locations — not 1,000, not 1,100, exactly 1,024. So "1 kilobyte of RAM" meant 1,024 bytes in practice because that was the actual physical block size.
Hard drive manufacturers never adopted the binary convention because it didn't suit them. A hard drive isn't built around power-of-2 block sizes the way RAM is — it's a physical spinning disk with sectors and tracks, and the engineers calculating capacity used straight decimal math. So when they labeled a drive "1 GB," they genuinely meant 1,000,000,000 bytes, not 1,073,741,824 bytes.
This wasn't dishonesty. Both groups were using the word "gigabyte" in the way that made sense for what they were building. The problem is that a consumer buying a hard drive and plugging it into a computer is bridging the two worlds — and the gap shows up immediately in the first number they see on screen.
The "missing" 69 GB on a 1 TB drive
Someone buys a 1 TB SSD. They plug it into Windows and see 931 GB. They immediately google "hard drive showing wrong size" and land on pages about disk formatting and hidden recovery partitions. Those pages aren't wrong — recovery partitions do take some space — but they're not the main reason for the 69 GB gap.
The main reason is entirely definitional. The manufacturer measured 1,000,000,000,000 bytes and called it 1 TB. Windows measured those same bytes using 1,073,741,824 bytes per GB and got 931.32 GB. The bytes are all there. Every single one of them. It's just a unit conversion mismatch, the same way saying "it's 100 degrees" means very different temperatures in Fahrenheit vs Celsius. Same number, different scale.
The MiB Fix That Nobody Actually Uses
In 1998, the International Electrotechnical Commission — the IEC — got tired of the ambiguity and proposed a clean solution. They created new names specifically for the binary units. Kibibyte (KiB) for 1,024 bytes. Mebibyte (MiB) for 1,048,576 bytes. Gibibyte (GiB) for 1,073,741,824 bytes. Tebibyte (TiB) for 1,099,511,627,776 bytes.
Under the IEC standard, "MB" would unambiguously mean 1,000,000 bytes — the metric definition — and "MiB" would unambiguously mean 1,048,576 bytes — the binary definition. Hard drive manufacturers could keep using MB. Operating systems could switch to MiB. Everyone would know exactly what each number meant. No more confusion.
In practice, almost nobody switched. The words "kibibyte" and "mebibyte" never entered everyday language. Linux adopted GiB labeling in some contexts. macOS switched to decimal (GB) in 2009, which actually made Apple drives appear to have slightly more space on screen than Windows showed for the same hardware. Windows still shows binary-calculated numbers but labels them GB rather than GiB. Most people have never heard the word "mebibyte" in their lives.
💡 Where you do see MiB in the wild
Linux distributions, especially in installer screens and disk utilities, will often show storage in GiB with the correct label. If you've ever installed Ubuntu and seen your 500 GB SSD listed as 465.6 GiB, that's the IEC standard being used properly. The number looks smaller because GiB is bigger than the manufacturer's GB — and the label is at least honest about which unit it's using. Developer tools, RAM profilers, and some network monitoring software also use MiB correctly. Outside these contexts, expect to see GB used loosely to mean either thing.
Why Your Hard Drive Always Shows Less Than Advertised
Now that the definition gap is clear, the math is straightforward. Take the number of bytes on your drive — exactly as the manufacturer measured them — and divide by the operating system's version of the unit to get what you'll see on screen.
Tracing the 1 TB drive through the full calculation
Manufacturer labels it "1 TB"
Measures exactly 1,000,000,000,000 bytes. Uses decimal TB = 10¹² bytes. Accurate by their definition.
Windows receives those same bytes
Divides by 1,073,741,824 (2³⁰) to get "GB." Gets 931.32. Displays "931 GB." Also accurate by its definition.
You see a 69 GB discrepancy
Both numbers refer to the same physical drive. The bytes are all there. The gap is a units conversion issue, not missing storage.
Quick mental check for any drive size
Multiply the advertised TB by 0.9095 to get approximately what Windows will show in "GB." A 2 TB drive shows ~1,819 GB. A 4 TB drive shows ~3,638 GB. The manufacturer's space is all there.
The confusion gets worse because formatting your drive for use does take a small additional chunk — the file system itself (NTFS, exFAT, ext4) needs space to store its own tables and metadata. On large modern drives this is small, maybe 200–500 MB. On top of the definitional gap, it adds a bit more distance between the box number and the screen number. Some drives also ship with recovery partitions pre-installed by manufacturers, which genuinely are extra space that Windows can see but not use freely.
But the recovery partition and file system overhead together account for maybe 10–20 GB on a typical drive. The majority of the gap on a 1 TB drive — 69 GB total — is the unit definition mismatch, not any actual missing space.
Why RAM Works Differently From Storage
Here's where it gets slightly interesting. RAM is always sold and reported in binary-aligned sizes. You don't see 8,000 MB RAM sticks — you see 8,192 MB (8 GiB) or 16,384 MB (16 GiB) or 32,768 MB (32 GiB). These are all powers of 2. When your system specs say 16 GB RAM, it actually means 16 GiB in binary terms — 17,179,869,184 bytes.
This is because RAM chips are physically built in binary-sized blocks. The addressing circuits, the memory controllers, everything about how RAM works is natively binary. There's no incentive or practical way for a RAM manufacturer to produce a 16,000,000,000-byte stick — the chips don't come in those sizes. So RAM manufacturers never had the same temptation that hard drive makers had to use decimal.
The result is that when Windows says you have 16 GB RAM, it means something slightly different than when it says your hard drive is 931 GB. The RAM number is accurate in binary terms. The hard drive number is the manufacturer's decimal figure recalculated in binary. Same label, different underlying math.
📌 The practical consequence of this for users
If you're running a machine with 8 GB RAM and a program needs 8,000 MB, you're fine — 8 GB RAM in binary is actually 8,192 MB. But if you're trying to copy an 8 GB file to a drive that shows "8.2 GB free," whether you'll succeed depends on which definition of GB the free space number is using. This kind of edge case is rare in daily use, but it's exactly where the ambiguity causes real problems in software development and server administration.
The Mbps vs MBps Trap That Catches Everyone
Storage confusion is one thing. Internet speeds have their own separate trap, and this one catches even people who understand the MB vs MiB issue.
Internet speeds are measured in bits, not bytes. A megabit per second (Mbps) and a megabyte per second (MBps) are not the same thing. One megabyte is 8 megabits. So a "100 Mbps" internet connection can transfer at most 12.5 megabytes per second — not 100 megabytes per second.
When you're downloading a file and your browser shows "12.3 MB/s," that's consistent with a 100 Mbps connection running at full speed. But it's very easy to read your plan as "100 MB" and feel like your 12 MB/s download is broken. ISPs advertise in Mbps because the numbers are 8 times larger and sound more impressive. Your download manager shows MB/s because bytes are what files are measured in. Nobody thinks to say that the units are different.
✗ The quick test for your connection
Take your plan's Mbps speed and divide by 8. That's the maximum MB/s you can realistically download at. A 200 Mbps plan maxes out around 25 MB/s. A 500 Mbps plan hits roughly 62 MB/s. If your speed test shows 200 Mbps and your file downloads at 22 MB/s, your connection is working fine — the difference is just bits vs bytes, plus normal overhead. If it's showing 5 MB/s, then yes, something is actually wrong.
There's a secondary layer to this: internet speed Mbps uses the decimal definition of mega (1,000,000 bits per second), while the MB/s your download manager shows may use either decimal or binary megabytes depending on the software. Usually it's decimal MB/s in browser download bars, which makes the bits-to-bytes conversion cleaner. But some download clients show MiB/s in binary. The units are in the label if you look carefully, but most people never look at units — they just see the number.
The Numbers Side by Side — Every Unit Decoded
| Unit | Name | Exact Bytes | Who Uses It | vs Previous |
|---|---|---|---|---|
| KB | Kilobyte (decimal) | 1,000 | Drive makers, network specs | ×1,000 |
| KiB | Kibibyte (binary) | 1,024 | Linux tools, dev software | ×1,024 |
| MB | Megabyte (decimal) | 1,000,000 | Drive makers, phone storage, macOS | ×1,000 |
| MiB | Mebibyte (binary) | 1,048,576 | Linux, RAM reporting | ×1,024 |
| GB | Gigabyte (decimal) | 1,000,000,000 | Hard drives, SSDs, USB drives, iOS | ×1,000 |
| GiB | Gibibyte (binary) | 1,073,741,824 | Windows (mislabeled as GB), Linux | ×1,024 |
| TB | Terabyte (decimal) | 1,000,000,000,000 | All hard drive/SSD packaging | ×1,000 |
| TiB | Tebibyte (binary) | 1,099,511,627,776 | Servers, storage arrays, Linux | ×1,024 |
| Mb | Megabit | 125,000 bytes | Internet speeds, network specs | ÷8 for MB |
| Gb | Gigabit | 125,000,000 bytes | Ethernet speeds (1 Gbps links) | ÷8 for GB |
The lowercase "b" vs uppercase "B" distinction is easy to miss in fonts that don't render them clearly. Mbps vs MBps is an 8x difference in actual transfer speed. It's a distinction that matters and one that the industry has never made effortless for consumers to spot.
What macOS did differently — and why it matters
Apple quietly switched macOS to decimal gigabytes in 2009 with Snow Leopard. Before that, Macs showed storage in binary GiB (mislabeled as GB) the same way Windows does. After the switch, the same 1 TB hard drive that shows 931 GB on Windows shows 1,000 GB on a Mac. The actual drive is identical. macOS just switched to the manufacturer's definition of the unit.
This led to a brief period of complaints from people switching from Mac to PC — their drive "shrank" by 7% when they booted Windows. It also led to some confusion in the other direction: people on Macs felt like they had more space than they did, because their system was reporting in a unit that matched the box but didn't match binary file sizes in the same way. Neither approach is wrong. They're just different answers to the same unit ambiguity.
Frequently Asked Questions
Yes, it's all there. Every single byte the manufacturer counted is present. The "missing" ~69 GB isn't locked away somewhere — it's a unit conversion discrepancy, not actual lost space. You cannot "recover" it because nothing is missing.
The only space you can potentially recover is from things like manufacturer recovery partitions (typically 5–20 GB, present on pre-built PCs and laptops) and leftover file system metadata. If you delete or repurpose a recovery partition, that space shows up as usable. But the ~69 GB gap itself? That's just the difference between how the drive was measured and how Windows reports it. You'll never close that gap through any software or formatting trick.
The hard drive industry had a legitimate financial reason not to switch to binary. If hard drive makers used binary gigabytes, a "1 TB" drive would need to contain 1,099,511,627,776 bytes to be honest — nearly 100 GB more physical storage than they were currently shipping. That's not a trivial cost difference per unit. Decimal gave them a larger-sounding number for less actual storage, while remaining technically accurate by metric standards.
On the software side, operating systems were already deeply embedded with binary conventions. File systems, memory allocators, cache systems — all were built around powers of 2. Switching to decimal internally would have required fundamental rewrites of core components. The IEC standard offered a clean solution but required everyone to learn new words ("mebibyte") and change established habits simultaneously. Neither group had enough incentive to do that. So the ambiguity just continued.
Two things are happening. First, the unit gap: 128 GB in decimal (the manufacturer's figure) is about 119.2 GiB in binary, so the ~9 GB difference is the definitional mismatch. Second, Android (and iOS to a lesser extent) pre-installs the operating system, core apps, and firmware onto the phone's storage before it ever reaches you. On a typical Android phone, the OS and pre-installed apps take 6–12 GB. On iPhones, iOS itself is compact but carrier apps and pre-loaded content add up.
Add both factors together and "128 GB" phones routinely show around 110–115 GB of usable space right out of the box. This is intentional and disclosed in the fine print of most phone specs sheets — "actual available storage may vary" — but the fine print doesn't explain why, so it always feels like a surprise when you first set up a new device.
The unit gap is exactly the same for SSDs as for hard drives. Both are sold using decimal gigabytes. Both show binary-calculated values in Windows. The math is identical.
SSDs do have one additional layer though: over-provisioning. Many SSDs reserve a percentage of their flash storage — typically 7–28% depending on the product tier — as reserved space that's invisible to the operating system. This reserved space is used to manage wear leveling, handle bad blocks, and maintain write performance. Enterprise SSDs often reserve more than consumer SSDs. This over-provisioned space is real storage you paid for that you simply cannot access, separate from the unit mismatch. Budget SSDs sometimes skip meaningful over-provisioning, which is one reason they wear out faster under heavy write workloads.
ISPs advertise in megabits per second (Mbps) because there are 8 bits in a byte, so the Mbps number is always 8 times larger than the equivalent MB/s number. A 200 Mbps plan sounds better than "25 megabytes per second" even though they describe the same maximum throughput. The practice is technically correct but makes comparisons confusing.
To convert: divide your Mbps plan speed by 8 to get the maximum download speed in MB/s. Then expect to get 70–90% of that maximum in practice due to protocol overhead, network congestion, and server-side limits. So a 100 Mbps plan realistically gives you 8–11 MB/s of download speed in real conditions. If you're consistently getting less than 60% of the theoretical maximum, that's worth investigating with your ISP. If you're hitting 80–90%, your connection is healthy.
Slightly, but not in a way that changes the fundamental unit gap. Formatting a drive to NTFS, exFAT, or any other file system causes Windows to allocate space for the file system's own internal tables — the MFT (Master File Table) on NTFS, for example. This overhead typically runs from a few MB on small drives to a few hundred MB on large ones. It's a real reduction in usable space, but it's small.
What formatting can actually help with is removing pre-existing partitions. If you buy a drive that came with a factory recovery partition (common on external drives sold with backup software pre-installed) and you don't want it, formatting the entire drive as a single partition gives you that space back. On a fresh bare drive with no pre-existing partitions, formatting changes the available space by less than 0.1% on drives above 500 GB. The unit mismatch is still there after formatting — that never changes.
Same Box. Same Drive. Different Numbers.
The MB vs MiB problem has been around for so long that most people have just accepted the discrepancy as one of those things computers do. The "missing" space on a new drive, the download speed that never matches the plan, the RAM that shows up as a slightly different number than the sticker — they all trace back to the same root cause: two industries using the same words for different values, and no one winning the argument about which one was right.
The IEC tried to fix it with MiB and GiB in 1998. Linux picked it up. Windows and the hardware industry mostly didn't. So today you're left reading labels that technically mean something specific but in practice mean whichever definition the author found convenient. Knowing this doesn't change the numbers on your screen, but it does mean you can stop wondering if something's wrong with your drive every time you open a new one out of the box.
The tools at 21k.tools handle file tasks in your browser — converting, compressing, splitting. When file sizes show up in those tools, they're reporting real bytes, which you can now map to whichever unit makes sense for your situation.
Comments (0)
Leave a Comment
No comments yet. Be the first to share your thoughts!