Binary vs Decimal Units: Which Should You Actually Use?

The Confusion Nobody Asked For

You buy a 1TB hard drive, plug it in, and Windows tells you it's 931 GB. Your friend insists the manufacturer ripped you off. The manufacturer says they did nothing wrong. Weirdly, both are correct — they're just speaking different languages.

This is the GiB vs GB problem, and it's been quietly causing arguments, support tickets, and genuine confusion since the 1990s. Let's put the two systems head to head and actually figure out which one to use — and when.

What's Actually Different Between GB and GiB

The root of everything is how computers count. Silicon doesn't think in tens; it thinks in twos. So early engineers, being practical, decided that 1 kilobyte would mean 1,024 bytes — because 2¹⁰ is 1,024, and that's conveniently close to 1,000.

That "conveniently close" part is what caused thirty years of headaches.

In 1998, the International Electrotechnical Commission (IEC) stepped in and formalized two separate systems:

  • Decimal (SI) units: 1 KB = 1,000 bytes, 1 MB = 1,000,000 bytes, 1 GB = 1,000,000,000 bytes. These are the units hard drive manufacturers use, and they're technically correct by international standards.
  • Binary (IEC) units: 1 KiB = 1,024 bytes, 1 MiB = 1,048,576 bytes, 1 GiB = 1,073,741,824 bytes. The "i" stands for "binary" — as in kibibyte, mebibyte, gibibyte. Operating systems traditionally report sizes this way, even if they label them wrong.

The gap between the two systems grows as the numbers get bigger. At 1 GB vs 1 GiB, you're off by about 73 megabytes. At 1 TB vs 1 TiB, the difference balloons to nearly 100 gigabytes. That's not a rounding error — that's a real discrepancy you'll feel.

Where Each System Actually Makes Sense

This isn't a case where one system is right and the other is wrong. They serve different purposes, and conflating them is where real mistakes happen.

Decimal units (GB, TB) make sense for:

  • Measuring storage capacity on hard drives and SSDs — this is what manufacturers ship, so it's what you compare when shopping
  • Network speeds and bandwidth — your ISP's 500 Mbps plan uses decimal megabits, and so does every router spec sheet
  • File transfer rates — when your browser says "downloading at 12 MB/s," it almost certainly means 12,000,000 bytes per second
  • Any context where you're talking to non-technical people who expect numbers to scale normally

Binary units (GiB, TiB) make sense for:

  • RAM — memory chips are manufactured in powers of two, so 16 GiB of RAM is exactly 16 × 2³⁰ bytes. There's no ambiguity here and no "close enough."
  • Partition sizes and filesystem allocation — when you tell a Linux formatter to create a 100 GiB partition, you want exactly that many bytes allocated
  • Virtual machine disk images — miscounting here causes subtle bugs and unexpected overflows
  • Any low-level systems work where precision to the byte actually matters

How Major Operating Systems Handle This (And Where They Get It Wrong)

Here's where the real-world confusion gets compounded: most operating systems use binary math but label the result with decimal letters. Windows is the most notorious offender.

When Windows Explorer says a file is 4.7 GB, it calculated the size in binary (dividing by 1,073,741,824) but printed "GB" instead of "GiB." macOS switched to using actual decimal GB in OS X Snow Leopard (2009), which is why your Mac and your Windows machine will report a different size for the exact same file. Neither is lying — they're counting differently.

Linux varies by tool. df -h uses binary math with decimal labels by default; df -H switches to actual SI decimal. The lsblk command uses powers of ten. du defaults to 1,024-byte blocks. It's a mess, and experienced sysadmins learn which tool does what through painful experience.

Android reports storage in decimal GB (aligned with what's printed on the box). iOS does the same since iOS 11. So if you've ever wondered why your iPhone and your old Windows laptop agreed on your file size but your Android disagreed with your Linux VM — now you know why.

How Conversion Tools Handle the Split

If you use online file-size converters or desktop utilities, their defaults matter enormously — and they vary wildly.

Some tools default to IEC binary prefixes and correctly label them GiB, MiB, etc. These tend to be built for developers or system administrators who care about precision. Others use decimal throughout, which is fine for general use but confusing if you're copy-pasting values into a partition tool expecting binary inputs.

The worst tools — and there are plenty — do binary math silently and slap a "GB" label on the result. If you're using a converter and it doesn't tell you which base it's using, assume it might be lying to you about units and verify with a second source.

A few things to check when evaluating any file-size converter:

  1. Does it explicitly distinguish between GB and GiB in its output?
  2. Can you toggle between decimal and binary modes?
  3. At 1 TiB input, does it output 1.0995 TB (correct) or 1.0 TB (wrong, or at least misleading)?

If a tool passes all three, it's actually built by someone who thought this through.

The 1 TB Drive That's Always 931 GB

Let's make the math concrete with the most common real-world example: the "missing" space on a hard drive.

A manufacturer labels a drive 1 TB. In their counting: 1,000,000,000,000 bytes. Windows reports this in binary math: 1,000,000,000,000 ÷ 1,073,741,824 = 931.3 GiB — but prints "931 GB."

You haven't lost anything. The bytes are all there. The drive holds exactly what was advertised, in the unit the advertiser used. The OS is just counting differently and mislabeling the result.

Now flip it: a system administrator provisions a virtual machine with "100 GB" of disk thinking in binary terms, but the tool creates a decimal 100 GB volume. That's actually 93.1 GiB — a 7% shortfall. In a database VM that expected exactly 100 GiB of storage headroom before it starts complaining, this causes a real problem.

The difference between "harmless label confusion" and "production incident" is whether you're shopping or engineering.

Practical Rules That Actually Help

After laying out the theory, here's what to actually do with it:

  • When shopping for storage: Use decimal GB. Compare manufacturer specs to manufacturer specs. Don't factor in what Windows will show you — that number will always be lower and that's fine.
  • When writing scripts or config files: Use binary units explicitly. If your tool supports it, write "100GiB" not "100GB" to be unambiguous. If it doesn't support that notation, add a comment explaining which base you mean.
  • When reporting to non-technical users: Decimal is cleaner and matches what people see on product packaging. Don't confuse them with GiB unless they need to know.
  • When troubleshooting "missing" disk space: First check whether you're comparing decimal and binary numbers before assuming the drive is faulty or the OS is corrupted.
  • When using a file-size converter: Check its documentation or test it with a known value (like 1 TiB = 1,099,511,627,776 bytes) to verify whether it's using binary or decimal math under the hood.

The Real Answer to "Which Should You Use?"

Neither system is universally correct. The honest answer is that you need both, and you need to know which one a given context expects.

The IEC made the right call in 1998 when they created distinct names for binary prefixes. The industry just never fully adopted the naming convention, which is why we're still here in 2024 explaining why your 1 TB drive shows up as 931 GB. If Windows, macOS, and Linux all correctly labeled their binary values as GiB, this entire article wouldn't need to exist.

Until that day arrives — and it probably won't — the best defense is knowing the difference yourself, checking your tools' defaults, and never assuming that "GB" means the same thing in two different pieces of software.

The 73 megabytes between 1 GB and 1 GiB won't matter when you're comparing flash drive prices. But if you're allocating memory for a container cluster or calculating how many files fit on a partition, those missing bytes have a way of showing up at the worst possible time.