Kibibyte (KiB)

A kibibyte (KiB) is exactly 1024 bytes. Defined by the IEC in 1998 as the unambiguous binary alternative to “kilobyte”, which had historically meant either 1000 or 1024 bytes depending on context. The mismatch is one of computing’s most persistent sources of confusion.

The full series of binary prefixes:

• KiB (kibi) = 2¹⁰ = 1,024 bytes
• MiB (mebi) = 2²⁰ = 1,048,576 bytes
• GiB (gibi) = 2³⁰ ≈ 1.07 × 10⁹ bytes
• TiB (tebi) = 2⁴⁰ ≈ 1.10 × 10¹² bytes
• PiB (pebi) = 2⁵⁰

In practice usage is split:

• Hard drive manufacturers: use the decimal prefixes (KB = 1000, GB = 10⁹). A “1 TB” drive holds 10¹² bytes, which Windows reports as “931 GB” because Windows uses binary GB (= GiB).
• Linux/macOS file systems: increasingly use the IEC prefixes (KiB, MiB).
• Windows file system: uses KB/MB/GB to mean 1024-based but with the SI prefix names — the source of the discrepancy users notice.
• RAM: always binary. 16 GB of RAM is 16 GiB; the “G” is loose terminology.
• Network rates: always decimal. 100 Mbps is 100 × 10⁶ bits/sec, not 100 × 2²⁰.

The pragmatic rule: when precision matters, use the IEC prefix (KiB, MiB) explicitly. For casual use, “KB” and “MB” are usually fine — but be aware which convention your tool is using when a number doesn’t quite match.

The class-action lawsuit that didn’t change anything: Western Digital, Seagate, and several other drive manufacturers settled class-action suits in 2007-2008 over the “1 GB = 1,000,000,000 bytes” labelling, paying out coupons and adjusting their disclosure language. The technical practice didn’t change — drive manufacturers continue to use SI decimal prefixes, and Windows continues to display binary capacities with SI labels. macOS switched to true SI labels in 10.6 (2009), so the same drive now shows “1 TB” on macOS and “931 GB” on Windows. The IEC prefix solution exists; market inertia keeps SI prefix names on binary quantities indefinitely.

The 2³² boundary nobody warns you about: 4 GiB is exactly 2³² bytes, which is the addressable range of an unsigned 32-bit integer. 32-bit operating systems (Windows XP 32-bit, older Linux) cannot directly address more than 4 GiB of RAM per process for this reason. The same constant explains the FAT32 filesystem’s 4 GiB file-size cap, the original IPv4 address space (2³² addresses), and the 2038 Unix-timestamp rollover (when signed 32-bit seconds-since-1970 overflows). Many software bugs cluster around values just over 4 GiB for exactly this reason. Related: bps, IEEE 754. Reference: IEC 80000-13 — Quantities and units — Information science and technology.

Worked example

You buy a drive marketed as “2 TB”. The vendor means decimal: 2 × 10¹² = 2,000,000,000,000 bytes. Windows divides that by 1024³ to display gibibytes-labelled-as-GB: 2,000,000,000,000 / 1,073,741,824 ≈ 1862.6 GB. So the drive that “said 2 TB” shows up as ~1.82 TB in File Explorer — neither number is a lie; they use different prefix conventions. Going the other way: a single uncompressed 4K frame at 3840×2160 pixels in 10-bit 4:2:2 video is 3840 × 2160 × 2.5 bytes/pixel ≈ 20.7 MB. At 24 fps for 90 minutes that is 20.7 × 10⁶ × 24 × 5400 ≈ 2.68 × 10¹² bytes, i.e. 2.68 TB decimal or 2.44 TiB binary — and so on for the storage planning spreadsheet.

When and why it matters

Capacity planning, RAID rebuild estimates, and cloud-storage billing all depend on which prefix the vendor used. AWS S3 and Azure Blob bill in decimal GB; many monitoring dashboards graph in binary GiB; alerts thresholded at “90% of 100 GB” misfire by ~7% when those two GBs are different units. If you size a backup destination by adding decimal source-file sizes but format the destination with a filesystem that reports in GiB, you can be 10% short and not realise until the final files. The defensive habit: when designing a system, write capacity numbers as raw bytes and only convert at the display layer, picking the prefix that matches the audience. Reference: NIST — Prefixes for binary multiples.