📐 File Size Unit Translator

The Quiet War Between Kilobytes and Kibibytes — And Why It Costs You Storage

Open the "Get Info" panel on a 16 GB USB drive and you will almost certainly see something like "15.7 GB (16,004,874,240 bytes)." The drive isn't defective. You haven't been cheated — at least not in the way most people assume. What you're looking at is the fundamental collision between two parallel numbering conventions that have coexisted uneasily in computing for decades: decimal file size units and binary file size units. Understanding the difference isn't pedantry. It changes how you size storage, plan backups, calculate network transfer times, and even interpret performance benchmarks.

Where the Two Systems Come From

Hard-drive manufacturers have always counted in powers of ten. A "1 terabyte" drive contains exactly 1,000,000,000,000 bytes — clean, round, and easy to market. Operating systems, on the other hand, were built around binary arithmetic from the very beginning. A processor naturally works in powers of two, so when early software engineers needed a shorthand for 1,024 bytes, they borrowed the existing metric prefix "kilo" because 1,024 is the closest power of two to 1,000. For years nobody cared much because the divergence was small — 2.4% at the kilobyte level, 4.9% at megabytes. At gigabytes the gap hits 7.4%. By the time you reach terabytes, a "1 TB" drive holds roughly 931 GiB, not 1,000 GiB. At petabyte scale the difference becomes enormous.

In 1998 the International Electrotechnical Commission tried to fix this permanently by introducing the binary prefixes: kibibyte (KiB = 1,024 bytes), mebibyte (MiB = 1,048,576 bytes), gibibyte (GiB = 1,073,741,824 bytes), and so on up through tebibyte, pebibyte, and exbibyte. The IEC standard is unambiguous — KiB means exactly 1,024 bytes, KB means exactly 1,000 bytes. Linux, BSD, and most engineering tools adopted these prefixes. Windows and many consumer applications still use "KB/MB/GB" to mean the binary values, which is technically incorrect but deeply entrenched. macOS made the switch to decimal in macOS 10.6 Snow Leopard (2009), which is why a file that "used to be 4.5 GB" under older macOS versions suddenly appeared as 4.83 GB after the update — the file didn't change, only the unit label did.

The Bit vs. Byte Distinction That Trips Up Network Math

There's a second axis of confusion layered on top of the decimal/binary split: bits versus bytes. Network speeds are almost universally quoted in bits per second. Storage sizes are almost universally quoted in bytes. This is not an accident — the industries developed independently and locked in their conventions early. A 100 Mb/s (megabit per second) Ethernet connection does not transfer 100 MB per second. It transfers 100 ÷ 8 = 12.5 MB per second. When your ISP advertises "1 Gigabit internet," that's roughly 125 MB/s of raw throughput in ideal conditions, not 1,000 MB/s. Knowing this translation matters enormously for estimating how long a large upload or download will take.

Bits also carry their own IEC prefixes: kibibit (Kib), mebibit (Mib), gibibit (Gib), and tebibit (Tib). These appear most often in memory bandwidth specifications and some networking contexts. A DDR5 RAM module rated at 51.2 GB/s is referencing the decimal gigabyte — 51,200,000,000 bytes per second — while the same spec written in binary might appear as approximately 47.68 GiB/s. Hardware specifications frequently mix these conventions within a single datasheet, which is why translating between them quickly is a genuine time-saver during system design.

Practical Scenarios Where Unit Confusion Creates Real Problems

Consider a few situations where getting the unit wrong leads to a concrete mistake. A developer allocating a 512 MiB buffer in an embedded system that only has 512 MB of RAM will overflow it — 512 MiB requires 536,870,912 bytes while 512 MB is only 512,000,000 bytes. The binary buffer is about 4.9% larger than the decimal one. A cloud engineer provisioning a 100 TB storage volume for a customer who specified "100 terabytes" needs to know whether that customer means decimal TB (common in backup software) or TiB (what Linux will report after mounting). The difference is nearly 9 TB. A video professional calculating whether a 2 TB external drive can hold 400 GB of footage needs to know that "400 GB" in their editing software might mean 400 × 1,073,741,824 bytes, not 400 × 1,000,000,000 — and that the drive's actual capacity in the editor's terms might be only about 1.82 TB.

Database administrators hit this constantly. SQL Server reports memory in megabytes using the binary definition. PostgreSQL's documentation mixes conventions depending on the version and the parameter being described. Kubernetes resource limits use the suffixes M (megabyte, decimal) and Mi (mebibyte, binary) side by side in the same YAML file, and setting the wrong one causes either memory waste or unexpected OOM kills in production.

Exabytes and Beyond: The Scale Where Errors Become Catastrophic

As data volumes at hyperscale companies grow into the exabyte range, the decimal/binary gap becomes operationally significant at a level that's hard to visualize. One exabyte (EB) is 10^18 bytes. One exbibyte (EiB) is 2^60 bytes — roughly 1.15 × 10^18 bytes. The gap between them is about 152 petabytes. AWS, Google, and Meta each store and process data at this scale, and their infrastructure teams are extremely precise about which convention applies to each subsystem. A miscommunication in capacity planning at that scale isn't an embarrassment — it's a multi-million-dollar procurement error.

Even at personal scale the exponent matters. Modern smartphones now ship with 1 TB of storage, and 4K ProRes video files routinely exceed 10 GB per minute. As consumer storage has grown, the absolute byte difference between "GB" and "GiB" has gone from being a rounding inconvenience to a meaningful planning gap. A user choosing between a 512 GB and 1 TB SSD upgrade should know that their operating system will report the 512 GB drive as approximately 476 GiB and the 1 TB drive as approximately 931 GiB.

How to Read Unit Labels in the Wild

A pragmatic field guide: hard drives, SSDs, and USB drives from manufacturers use decimal (GB, TB). RAM capacity labels from manufacturers use binary (so a "16 GB" stick actually contains 16 × 2^30 = 17,179,869,184 bytes, even though no IEC label appears). Windows Explorer reports file sizes in binary but labels them "GB" — technically wrong but consistent. macOS Finder has used decimal since 2009. Linux tools like df default to binary (use df -H for decimal). Network equipment datasheets use bits per second in decimal. Memory bandwidth is usually quoted in decimal gigabytes per second. GPU VRAM is labeled in binary gigabytes but marketed with the "GB" label.

The cleanest way to end ambiguity in any context where precision matters is to express the quantity directly in bytes — no prefix, no convention dispute. 16,384 bytes is 16,384 bytes regardless of what acronym surrounds it. For human-readable communication, using the correct IEC prefix (MiB, GiB, TiB) is the next best option, even if it feels unusual at first. The file-size translation tool above converts across all of these systems simultaneously so you can verify any claim and communicate precisely — especially across the binary/decimal boundary where misunderstandings are most expensive.