Why a 1 TB drive shows as 931 GB
Two counting systems collided, and both are still in use. Drive manufacturers use the SI decimal prefixes, where kilo means a thousand, mega a million, giga a billion and tera a trillion. So a drive sold as 1 TB contains exactly 1,000,000,000,000 bytes, and its packaging usually says so in small print.
Operating systems, and particularly Windows and most file managers, count in powers of two, because memory addressing is binary and the habit spread from there to storage. In that system a “gigabyte” is 230 = 1,073,741,824 bytes. Divide the drive's 1,000,000,000,000 bytes by that and you get 931.32, which the operating system then labels GB. The bytes did not go anywhere; only the divisor changed.
The gap widens at every step up the scale, because each prefix multiplies the discrepancy again. A kibibyte is 2.4% larger than a kilobyte, a mebibyte 4.86% larger than a megabyte, a gibibyte 7.37% larger than a gigabyte and a tebibyte 9.95% larger than a terabyte. Read the other way — which is the direction that annoys people — a decimal terabyte is 9.05% smaller than the tebibyte it gets displayed as.
IEC 60027-2 introduced the unambiguous binary names in 1998, and they now sit in IEC 80000-13: kibibyte (KiB), mebibyte (MiB), gibibyte (GiB), tebibyte (TiB). Linux and macOS have largely adopted them, storage vendors quote decimal units, and Windows continues to show binary quantities with decimal labels, which is the single largest source of the confusion.
The conversion, and where the constants come from
Every conversion goes through bytes. Multiply the value by the number of bytes in its own unit, then divide by the number of bytes in the target unit. Nothing else is involved, and the arithmetic is exact because every factor is an exact integer.
Decimal factors are powers of 1000: 1 KB = 103, 1 MB = 106, 1 GB = 109, 1 TB = 1012, 1 PB = 1015 bytes.
Binary factors are powers of 1024: 1 KiB = 210 = 1,024; 1 MiB = 220 = 1,048,576; 1 GiB = 230 = 1,073,741,824; 1 TiB = 240 = 1,099,511,627,776; 1 PiB = 250 = 1,125,899,906,842,624 bytes.
The two ratios worth memorising fall straight out of those. Going from decimal to binary at the same scale, divide by 1.073741824 for GB to GiB and by 1.099511627776 for TB to TiB — equivalently, multiply by 0.931322574615479 and 0.909494701772928. Going the other way, multiply by 1.073741824 and 1.099511627776.
Notice that the percentage gap is not the same in both directions, and mixing them up is a common slip. A tebibyte is 9.9511627776% larger than a terabyte, because 1.099511627776 − 1 = 0.099511627776. But a terabyte is only 9.0505298227072% smaller than a tebibyte, because 1 − 0.909494701772928 = 0.090505298227072. Both statements describe the same pair of numbers; the denominators differ.
One more constant appears in networking rather than storage, and it causes a separate confusion: a megabit is not a megabyte. Line rates are quoted in bits per second and file sizes in bytes, a factor of eight, which the Mbps to MB/s calculator handles. Storage prefixes and bit-versus-byte are independent problems, and a transfer estimate can be wrong by both at once.
Worked example: a 4 TB drive in a two-drive mirror
You buy two 4 TB drives and mirror them. The array should show 4 TB of usable space. The operating system reports 3.64 TB. Work out whether anything is wrong.
- Convert the label to bytes. 4 TB × 1012 = 4,000,000,000,000 bytes on each drive.
- Apply the mirror. A two-drive mirror stores one copy, so usable capacity is 4,000,000,000,000 bytes, not 8.
- Convert to tebibytes. 4,000,000,000,000 ÷ 1,099,511,627,776 = 3.637978807091713 TiB. Windows displays that as “3.63 TB” after rounding down, which is where the missing 0.36 appears to come from.
- Convert to gibibytes for a second view. 4,000,000,000,000 ÷ 1,073,741,824 = 3,725.290298461914 GiB. Multiply back: 3,725.29 × 1,073,741,824 ≈ 4 × 1012, which confirms the arithmetic.
- Quantify the apparent loss. 4 − 3.637978807091713 = 0.362021192908287, and 0.362021192908287 ÷ 4 = 9.0505%. That is exactly the TB-to-TiB gap, unchanged by the drive size, so it is a labelling difference and not a capacity loss.
- Account for the rest. The formatted file system will report a little less again — typically a fraction of a percent for metadata, inodes and journal, and more if the file system reserves blocks for the root user. That part is a genuine reduction in what you can store, unlike the unit conversion.
The useful habit is to do step 5 first whenever a capacity looks wrong. If the shortfall is 9.05% at the terabyte scale or 6.87% at the gigabyte scale, it is units. Anything else needs a different explanation.
Where each convention actually appears
Hard drives and SSDs are sold in decimal units. A 500 GB drive holds 500,000,000,000 bytes. This has been settled by litigation as well as by standards bodies, and every manufacturer now states the definition on the packaging.
RAM is sold in binary units. A 16 GB memory module is 16 × 230 = 17,179,869,184 bytes, because memory is addressed by binary address lines and a power-of-two size is physically inherent. Memory is the one place where the binary reading is unambiguous, and it is why the habit exists at all.
Windows reports binary quantities with decimal labels. File Explorer's “GB” is a gibibyte. macOS switched to decimal units in Mac OS X 10.6, so the same drive reports a larger number there than on Windows — both are correct, and neither machine has more space than the other.
Networking is decimal and counted in bits. A 1 Gbps link carries 1,000,000,000 bits per second, which is 125,000,000 bytes per second, or about 119.2 MiB/s. Two separate conversions, applied in the wrong order, are how transfer estimates end up 15% out.
Cloud storage is quoted decimally and billed on bytes stored. Provider consoles and invoices use GB and TB in the decimal sense, so 1 TB of objects means 1012 bytes. That matters when comparing an on-premises array's reported free space, which is likely binary, against a cloud bill, which is not.
Advertised drive capacity against what the operating system shows
| On the box | Exact bytes | Shown as GiB | Shown as TiB | Apparent shortfall |
|---|---|---|---|---|
| 256 GB | 256,000,000,000 | 238.42 | 0.2328 | 6.87% |
| 500 GB | 500,000,000,000 | 465.66 | 0.4547 | 6.87% |
| 1 TB | 1,000,000,000,000 | 931.32 | 0.9095 | 9.05% against TiB |
| 2 TB | 2,000,000,000,000 | 1,862.65 | 1.8190 | 9.05% against TiB |
| 4 TB | 4,000,000,000,000 | 3,725.29 | 3.6380 | 9.05% against TiB |
| 8 TB | 8,000,000,000,000 | 7,450.58 | 7.2760 | 9.05% against TiB |
| 16 TB | 16,000,000,000,000 | 14,901.16 | 14.5519 | 9.05% against TiB |
| 20 TB | 20,000,000,000,000 | 18,626.45 | 18.1899 | 9.05% against TiB |
The GB rows quote the gap against GiB (6.87%) and the TB rows against TiB (9.05%), because those are the units the operating system displays at each scale.
Where this goes wrong in practice
- Comparing a vendor's capacity against an operating system's report. Convert both to bytes before deciding anything is missing.
- Assuming the file system's number is the unit gap. Formatting costs a further amount for metadata and reserved blocks, and that part is a real reduction rather than a labelling difference.
- Mixing bits and bytes with decimal and binary. A 1 Gbps link is 125 MB/s decimal, which is about 119.2 MiB/s binary. Applying only one of the two conversions leaves an error of 7–12%.
- Sizing an array from binary figures and buying decimal drives. Needing 10 TiB of usable space means buying at least 10.995 TB of decimal capacity before RAID overhead, not 10 TB.
- Quoting the gap in the wrong direction. A tebibyte is 9.95% larger than a terabyte; a terabyte is 9.05% smaller than a tebibyte. Both are right and they are different numbers.
- Assuming SSD capacity behaves the same way. Solid-state drives are also sold decimally, but they additionally reserve part of the flash for over-provisioning, which is invisible to the host and separate from any unit conversion.
Why the two systems both survive
The binary convention began as a convenience. Memory sizes are inherently powers of two, 1,024 is within 2.4% of 1,000, and early computing simply reused the SI prefixes for the nearby binary quantities. The approximation was harmless at the kilobyte scale and became steadily less so with each new prefix — by the petabyte the two systems differ by more than 11%.
IEC 60027-2 fixed the ambiguity in 1998 by giving the binary quantities their own names, and IEC 80000-13 carries them today. Adoption has been partial: Linux tooling, macOS, and most storage and networking standards use the units precisely, while Windows and a great deal of consumer software still display binary values with decimal labels. Until that changes, the safest habit is to state byte counts when precision matters and to convert explicitly when it does not.
The practical consequence for capacity planning is that binary and decimal figures must never be mixed in a single sum. A requirement expressed in TiB has to be converted to TB before drives are ordered, and an array's raw capacity has to be converted to binary units before it is compared with a file system's report. Add RAID overhead to that and the chain gets long: the RAID capacity calculator handles the protection arithmetic, and the data compression ratio calculator covers the reduction claims layered on top. For a plain conversion between any two data units, including bits, the data storage unit converter is the broader tool.
One last note on where the number goes next. Backup sizing, egress billing and transfer estimates all start from a byte count, and each of them has its own convention: backup software usually reports binary, cloud invoices decimal, and network tools bits. When an estimate is out by roughly 7%, 9% or a factor of eight, the cause is almost always a unit and almost never the storage.