KB, MB, GB, TB: Why Your Computer Can't Count to 1,000

1. Why There Are Two Definitions of the Same Four Letters

In 1795, the French Academy of Sciences defined "kilo" as one thousand. For 150 years, this was uncontroversial. A kilometer was 1,000 meters. A kilogram was 1,000 grams. A kilowatt was 1,000 watts. "Kilo" meant a thousand, always and everywhere, until computer engineers needed a word for 1,024.

The problem is that 1,024 is not 1,000. It's close �?close enough that early computer engineers used "K" as a shorthand. A 4,096-word magnetic core memory was "4K." 4,096 is 4 × 1,024. Calling it "4K" was a convenient, memorable, and sufficiently accurate label in an era when a "kiloword" of memory cost more than a car and the people buying it were electrical engineers who understood the binary convention implicitly.

This linguistic borrowing was an accident of history, not a conspiracy. In 1956, when IBM shipped the first hard drive �?the RAMAC 305, storing 5 million 7-bit characters on fifty 24-inch platters �?the term "megabyte" didn't exist yet. Engineers described storage in "characters" or "words." By the late 1960s, as semiconductor memory became addressable in clean powers of two, "K" and "M" had become standard shorthand among computer architects. Nobody sat down and decided that "kilobyte" would officially mean 1,024 bytes. It happened the way slang happens: a group of practitioners found a convenient shorthand, and it stuck.

The marketing departments noticed the ambiguity in the 1980s, when hard drives reached capacities large enough for the 2.4% gap to become visible. A drive with 10,000,000 bytes could be labeled "10 MB" (decimal) or "9.5 MB" (binary). The bigger number sold more drives. The binary camp �?memory manufacturers, operating system developers, and the IEEE �?continued using powers of two because memory chips are physically built around binary addressing. The split was never resolved by authority. It was resolved by inertia: each industry kept doing what it had always done, and consumers were left to notice the discrepancy on their own.

2. The Electrical Engineer's Instinct: Why Computers Count in 1,024

A computer memory chip does not count to ten. It counts to two. Every address line on a memory bus can carry a 0 or a 1. With one address line, you can select exactly two memory locations: address 0 and address 1. With two address lines: four locations (00, 01, 10, 11). Three lines: eight. Four lines: sixteen. The number of addressable locations doubles with each additional line �?that's exponential growth, and the base of the exponent is always 2.

With 10 address lines, you can address exactly 1,024 locations. Not 1,000. If you designed a memory chip with 10 address lines and only used 1,000 of the possible 1,024 addresses, you'd be throwing away 24 perfectly good locations and complicating the address decoder circuitry �?adding cost and latency for no engineering benefit. So memory chips use all 2ⁿ locations. 1,024 was not chosen because it's a nice round number. It was chosen because it's 2¹⁰, and 2¹⁰ is the inevitable consequence of ten binary address lines.

The table reveals a pattern that is obvious in hindsight: the error grows with each prefix level because the error is multiplicative. At each step from kilo to mega to giga to tera, you multiply by another factor of 1,024 while the SI convention multiplies by 1,000. After four prefix levels (kilo �?mega �?giga �?tera), the cumulative ratio is (1,024/1,000)⁴ �?1.10 �?a 10% gap.

Why hard drives don't use binary. A hard drive stores bits on magnetic platters arranged in concentric tracks. The number of bits per track is determined by the physical geometry of the platter and the density of the magnetic coating �?not by the number of address lines on a bus. A drive can store 512 bytes per sector, 63 sectors per track, and 16,383 cylinders �?producing a capacity of exactly 500,118,528 bytes if the manufacturer chooses those numbers. The capacity is an arbitrary integer, not a power of two. So hard drive manufacturers, from the very beginning, used decimal prefixes because the numbers they were describing were decimal numbers. A 500,118,528-byte drive is "500 MB" in the decimal convention. In binary, it's 476.9 MiB �?a number that looks like a defect on the spec sheet. Marketing chose the bigger, rounder number. Engineering could not argue that it was wrong �?because the engineering definition was always informal.

3. 1998: The Year the IEC Tried to Fix It (and Nobody Listened)

By the mid-1990s, the dual definition had become a genuine problem. Hard drives were shipping in gigabyte capacities, and the gap between decimal and binary gigabytes was 7.4% �?enough for consumers to notice and complain. Network engineers specifying "megabit" line rates and storage engineers provisioning "megabyte" arrays were using the same prefixes to mean different quantities. A disk array spec'd at "1 TB" could be 1,000,000,000,000 bytes or 1,099,511,627,776 bytes �?a difference of 100 GB, which in 1998 was more storage than most companies owned in total.

In December 1998, the International Electrotechnical Commission (IEC) published Amendment 2 to IEC 60027-2, introducing a set of binary prefixes that were deliberately distinct from the SI decimal prefixes:

The naming scheme was both elegant and transparent. Take the first two letters of the SI prefix ("ki" from "kilo," "me" from "mega," "gi" from "giga," "te" from "tera") and append "bi" for "binary." The resulting words �?kibibyte, mebibyte, gibibyte, tebibyte �?were unambiguous. A kibibyte was always 1,024 bytes. A kilobyte was always 1,000 bytes. No more guessing. The standard was incorporated into ISO/IEC 80000-13 in 2008, giving it the weight of the international standards bodies that define the meter, the kilogram, and the second.

And then almost nobody adopted them.

In 2026, twenty-eight years after the standard was published, the dominant operating system on the planet �?Microsoft Windows �?still labels everything in KB, MB, GB, and TB, and still uses the binary definition. File Explorer says "1,024 KB" when it means 1 MiB. Task Manager reports memory in binary GB. The words "kibibyte" and "mebibyte" appear nowhere in the Windows UI. macOS switched to decimal in 2009 �?but it still uses the labels KB, MB, GB, not KiB, MiB, GiB. Linux distributions are split: Ubuntu's file manager (Nautilus) uses decimal KB/MB/GB by default, while command-line tools like ls -lh use binary but print "K" and "M" without clarification. The only major software ecosystem that consistently uses KiB/MiB/GiB is the Linux kernel itself �?in /proc/meminfo, in driver documentation, and in filesystem tools �?and even there, adoption is inconsistent across user-facing utilities.

Why did the standard fail? Three reasons. First, "gibibyte" sounds ridiculous in English �?the doubled "bi" syllable reads as a stutter, and "kibibyte" to an English speaker's ear is baby-talk. Technical documentation writers, who decide what names become canonical through sheer repetition, rejected the new terms on aesthetic grounds. Second, the standard solved a problem that most people had already learned to live with �?the 7% gap was annoying but not dangerous, and the workaround (just buy a bigger drive) was cheap. Third, and most fundamentally, the standard asked the entire world to change its vocabulary to resolve an ambiguity that only electrical engineers and IT professionals fully understood. The average computer user has never heard the word "kibibyte" and never will �?not because the standard is wrong, but because the standard addressed a precision requirement that only a tiny fraction of users have.

The IEC tried. The standard exists. It is correct. It just never won. The result in 2026 is that a "gigabyte" can mean either of two numbers 7.4% apart, and you figure out which one from context �?or you ask for the byte count directly. Every data storage engineer learns to do this in their first month on the job.

4. Windows vs. macOS vs. Linux: Three Operating Systems, Three Interpretations

The same file, copied onto three different computers, will show three different sizes �?not because the file changed, but because the operating systems count differently.

Windows. Microsoft has used binary prefixes internally since MS-DOS. Every version of Windows �?95, XP, 7, 10, 11 �?defines 1 KB = 1,024 bytes in File Explorer, in disk properties, in dir output, and in every system dialog. Windows Server does the same. This is not documented in a user-facing setting; there is no toggle, no registry key, no Group Policy to switch to decimal. Microsoft's position, stated consistently in its developer documentation since the early 2000s, is that the binary definition is what Windows users expect and a change would cause more confusion than it resolved. Given Windows' roughly 70% desktop market share, this single decision means that a majority of the world's computer users see binary-labeled storage sizes every day �?and most of them don't know it.

macOS. Apple switched to decimal prefixes in Mac OS X 10.6 Snow Leopard (2009). Every version since �?Lion, Mountain Lion, Mavericks, through to Sequoia �?reports file and disk sizes in decimal KB/MB/GB/TB. A 1 TB (decimal) hard drive plugged into a Mac will report "1 TB" in Finder �?exactly matching the box. This was a deliberate design choice: Apple decided that consumer expectations (matching the box) mattered more than engineering tradition (matching the memory architecture). The decision was controversial among developers at the time but has been largely uncontroversial in the consumer market. Most Mac users have no idea that their file sizes are reported in a different unit than their Windows-using colleagues see for the same file.

Linux. The situation is, characteristically, the most complicated. The Linux kernel internally uses binary units and often prints KiB/MiB/GiB in kernel messages �?it's one of the few software components that consistently adopted the IEC standard. But user-facing tools are split. GNOME's Nautilus file manager uses decimal (like macOS). KDE's Dolphin uses decimal. The ls -lh command uses binary with single-letter suffixes (K, M, G). The df -h command on some distributions uses binary, on others decimal. The du command's default is binary. You can force consistency with ls --si (decimal) or df -H (decimal), but the defaults vary by distribution and sometimes by package version. If you manage Linux servers and macOS desktops in the same organization, every storage report contains a latent 2.4%�?0% discrepancy that is invisible unless you check which convention the reporting tool uses.

The practical rule. If you are comparing file sizes or disk usage across operating systems, get the byte count. Every OS can report the raw byte count �?it's the one number that is definitionally unambiguous. Windows: right-click �?Properties shows "Size: 1,234,567,890 bytes." macOS: Finder �?Get Info shows the byte count in parentheses. Linux: ls -l (no -h) prints the byte count directly. Convert from bytes to whatever label you need, but always start from bytes when crossing OS boundaries.

5. The Consumer Lawsuits: When the 7% Gap Went to Court

The gap between decimal and binary gigabytes became a legal question in the early 2000s, when a series of class-action lawsuits were filed against hard drive manufacturers in US federal courts. The plaintiffs argued that consumers were being misled �?that a drive labeled "80 GB" should deliver 80 billion bytes as the consumer's operating system counted them, not as the manufacturer defined the term.

Did the lawsuits change anything? Yes �?but not in the way the plaintiffs hoped. No court ordered manufacturers to ship more bytes. No court required packaging to use KiB/GiB prefixes. Instead, the lawsuits produced a single, durable industry practice: every hard drive box now carries a disclaimer defining exactly what the manufacturer means by GB or TB. "1 GB = 1,000,000,000 bytes" or "1 TB = 1,000,000,000,000 bytes" appears on the packaging of every major hard drive brand sold in the United States. The disclaimer is the permanent legal scar tissue of the 2004�?007 litigation. Consumers still get confused. They just can't sue over it anymore �?the disclaimer inoculates the manufacturer. The operating system still reports a smaller number. The box still warns you that this will happen. Nobody is lying. The system works. It's just not the system anyone would design from scratch.

Flash storage (SSDs, USB drives, SD cards) uses the same decimal convention as hard drives. A "256 GB" SSD is 256,000,000,000 bytes �?and Windows will report approximately 238 GB. The gap is identical in percentage terms to a mechanical hard drive, and the same disclaimer appears on the packaging. RAM is the exception: a "16 GB" RAM stick is genuinely 16 × 1,073,741,824 = 17,179,869,184 bytes �?approximately 17.2 "decimal GB." RAM manufacturers use binary prefixes because RAM is manufactured in capacities that are powers of two (for the addressing reasons explained in Section 2). The RAM stick's 16 GB label is telling the truth in binary �?and Windows, helpfully, agrees with it, because Windows also uses binary. RAM is the one category of computer hardware where the box and the OS display the same number. This accidental consistency �?both sides independently chose binary �?has probably prevented more consumer confusion than any deliberate standardization effort.

6. When the 7% Gap Becomes Real Money: Cloud Billing, NAS Arrays, and Video Pipelines

For a consumer buying one hard drive, the 7%�?0% gap between decimal and binary is an irritation �?the difference between 931 GB and 1,000 GB on a $60 drive is about $4 of effective capacity. For a data center operator buying 10,000 drives, it's a budget-line error. For a cloud provider billing customers by the "GB-month," it's a revenue question with nine zeros behind it.

6.1 Cloud Storage Billing

Amazon S3, Google Cloud Storage, and Microsoft Azure Blob Storage all bill by the "GB-month" �?but each defines the gigabyte differently. AWS defines 1 GB = 1,000,000,000 bytes (decimal). Google Cloud uses the same decimal definition. Azure uses decimal. The consistency is recent �?before 2014, several cloud providers used binary GB in their internal metering while displaying decimal GB on customer invoices, producing bills that were systematically 7.4% higher than customers calculated from their own binary-based tools. Organizations that monitored cloud storage with on-premises monitoring software calibrated to binary units routinely over-provisioned by 7% �?paying for storage they didn't need because the monitoring tool and the billing system spoke different dialects of the same word.

The industry has largely converged on decimal for billing �?partly to match customer expectations set by hard drive boxes, and partly because decimal numbers are easier for finance departments to audit. But the converged standard is informal. No regulation requires cloud providers to define GB on the invoice. If your organization's internal storage monitoring uses binary GB (as Windows Server and many Linux tools do by default), your monitoring dashboard will systematically under-report costs by 7.4% relative to your cloud bill. The fix is simple �?convert everything to bytes before comparing �?but the fix is not automatic, and it requires someone to notice the discrepancy first.

6.2 NAS and RAID Arrays

A 12-bay NAS populated with 20 TB (decimal) drives advertises "240 TB raw capacity" on the spec sheet. The marketing number is decimal: 240,000,000,000,000 bytes. After RAID-6 (dual parity, losing two drives' worth of capacity to redundancy), the usable decimal capacity is roughly 200 TB. But the NAS operating system �?Synology DSM, TrueNAS, QNAP QTS �?typically reports usable capacity in binary TiB (though labeled "TB"). A 200 TB decimal array reports as 181 TiB �?a 10% drop. Combined with filesystem overhead (typically 2�?%), the final usable space visible to the client OS can be 170�?75 TiB �?29% less than the "240 TB" on the box. The missing storage is not lost. It's the cumulative effect of (a) decimal-to-binary conversion, (b) parity overhead, and (c) filesystem metadata �?three independent reductions, each legitimate, each compounding on the previous. Procurement departments that don't account for all three will under-buy storage by a margin that compounds with every array refresh.

6.3 Video Production Pipelines

A 1-hour Apple ProRes 422 HQ 4K video file is approximately 750 GB (decimal) �?750,000,000,000 bytes. A post-production facility managing 200 hours of raw footage needs about 150 TB of working storage, plus backup. If the facility's Mac-based editorial team sees "1.12 TB" on a backup volume (decimal, like all macOS volumes) and the facility's Linux-based backup server reports the same volume as "1.02 TB" (binary, like many Linux backup tools), the discrepancy looks like data corruption to a producer who doesn't know about the convention split. Post-production schedules have been delayed while technicians verified that the missing 100 GB was not missing data but a measurement-unit mismatch �?a single miscommunication that would not have happened if both systems reported in bytes, or if the IEC standard had been adopted universally in 1998.

6.4 The Petabyte Problem

At the petabyte scale, the gap is approximately 12.6%. A 1 PB (decimal) storage cluster is 1,000,000,000,000,000 bytes. In binary, it's 0.888 PiB. A data center architect specifying "1 PB of usable storage" who gets 0.888 PiB instead is short by 112 TB �?roughly 7�?1 enterprise hard drives' worth of capacity. At current (2026) enterprise HDD pricing, that's approximately $2,000�?4,000 in missing hardware �?per petabyte. A 50 PB deployment is short by roughly $100,000�?200,000 of expected capacity if the decimal/binary distinction wasn't clarified in the purchase order. Every hyperscale cloud operator has internal standards that specify storage in bytes precisely for this reason. No Google SRE provisions a cluster in "petabytes" �?they provision in bytes, and the tooling converts to whichever prefix the dashboard user prefers. The lesson from data centers is the same as the lesson from file comparisons across operating systems: when it matters, count bytes. The prefixes are a display-layer convenience. The byte is the atomic truth.

7. Every Data Storage Converter on This Site

Eight converters covering the four prefix levels (kilo through tera) in both directions. Each uses the binary definition (1 KB = 1,024 bytes, 1 MB = 1,048,576 bytes, etc.) �?matching what Windows, most Linux tools, and all memory specifications use. If you need the decimal definition (hard drive marketing, macOS Finder, cloud billing), multiply the binary result by the appropriate factor from the Quick Reference table at the top of this page.

KB ↔ MB �?the everyday pair

Images, documents, small downloads. A 5 MB photo is 5,120 KB. A 500 KB PDF is 0.488 MB. These two converters handle the scale most people work with daily. 1 MB = 1,024 KB.

MB ↔ GB �?the media and software scale

Software installers, video files, system memory. A 16 GB RAM stick is 16,384 MB. A 250 MB application download is 0.244 GB. 1 GB = 1,024 MB.

GB ↔ TB �?the drive and backup scale

Hard drives, SSDs, NAS volumes. A 2 TB drive is 2,048 GB in binary. Remember: the box on a "2 TB" drive means 2,000,000,000,000 bytes (decimal), which Windows will report as 1.82 TB. 1 TB = 1,024 GB.

KB ↔ GB �?crossing three prefix levels

Log files, database dumps, memory dumps. A 1 GB file is 1,048,576 KB. These skip the intermediate MB level �?useful when comparing storage at very different scales. 1 GB = 1,048,576 KB.