Convert GB to GiB

A gigabyte is a billion bytes in the decimal sense used by drive manufacturers, phone plans and video sizes.

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

The factor is 0.931323, and almost nobody carries that around. Rounded to 0.93 it is off by 0.14 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 GB.

That is the number worth knowing before you round: not the error itself, but where it stops being ignorable. Below that point the shorter factor is the sensible one; above it, use the field above, which never rounds until it prints.

One GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1.0737 GB and 1 GB — 7.4 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 1 GB where the box said 1.0737. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

The drive holds exactly what the box promises: 1,000,000,000,000 bytes, because a manufacturer terabyte is a trillion bytes and always has been. Windows then divides that number by 1,024 three times, arrives at 931.32, and prints the letters GB beside it. Nothing has been lost, no partition is hidden and no vendor has shaved anything off. The same bytes have been counted in a different unit and handed the older unit’s name, and the 68 GB that appear to be missing never existed as bytes at all.

Doing the arithmetic once stops it looking like a coincidence. A gibibyte is 1,073,741,824 bytes, so a decimal gigabyte is 1,000,000,000 ÷ 1,073,741,824 = 0.93132257 GiB. Multiply by a thousand and 1 TB becomes 931.32 GiB. The same factor explains every capacity on the shelf: a 500 GB SSD reports 465.66, a 2 TB drive 1,862.65, a 256 GB phone 238.42. The shortfall is a shade under 6.9 per cent every time.

Multiply the advertised figure by 0.93132257, or divide it by 1.073741824 — the two are the same operation. A capacity quoted in terabytes needs a further multiplication by 1,000 first, because the reporting is almost always done in the gigabyte-sized unit whatever the box said. That is why a 4 TB drive appears as a four-digit number of GB rather than as 3.6 of anything.

The results worth memorising, because they recur: 128 GB is 119.21 GiB, 512 GB is 476.84, 1,000 GB is 931.32, 4,000 GB is 3,725.29 and 8,000 GB is 7,450.58. Set those beside the number the drive properties dialog shows and they will agree to within a gigabyte or two, the remainder being the file system rather than the unit.

The unit conversion happens before the disk is formatted, and the file system then claims space of its own. NTFS reserves a zone for the master file table, ext4 keeps five per cent of the volume for the root user by default, and every file system carries allocation tables and journals. These are real bytes, genuinely unavailable, and they are what turns 931.32 GiB of raw capacity into a slightly lower figure of free space.

The scale is worth keeping straight. On a one-terabyte volume the ext4 root reservation alone is about 46 GiB, which is large enough to notice and can be lowered with the file system tools; NTFS overhead on the same volume is usually a few gigabytes. Neither is anywhere near the 68 GB the unit change appears to remove, so a reader chasing the difference should settle the unit question first and the formatting question second.

Windows File Explorer, the drive properties dialog and Task Manager all divide by 1,024 and label the result GB. So do the GNU coreutils in their default human-readable mode: df -h, du -h and ls -lh show a G suffix that means 2³⁰ bytes, and the --si flag is what switches them to powers of a thousand. Most Linux desktops inherit that behaviour, which is why a fresh install disagrees with the invoice.

macOS is the exception among consumer systems and has been since 2009, when Snow Leopard moved storage reporting to decimal units. The same external drive therefore reads 1 TB on a Mac and 931 GB on a Windows machine plugged into the same port a minute later. Neither is wrong and neither has re-measured anything; the byte count sitting on the platter is identical in both cases.

Memory is reached through binary address lines, so a chip’s capacity is a power of two whether anybody finds that convenient or not. Ten address lines give 1,024 locations, which is within 2.4 per cent of a thousand, and early programmers borrowed the prefix kilo for it rather than inventing a word. At that scale the borrow was harmless and it stuck.

Storage never had the constraint. A platter’s capacity is set by track and sector geometry rather than by an address bus, so drive makers counted in thousands from the beginning and their boxes still carry the footnote saying that one gigabyte means 1,000,000,000 bytes. The two conventions were applied to different hardware and never reconciled, and the conflict only became visible to ordinary users once one operating system started reporting the other industry’s product.

Take seven per cent off and the answer is close enough to argue with. A terabyte becomes about 930, two terabytes about 1,860, and 500 GB about 465 — each within a gigabyte or two of the exact figure. For anything below a terabyte the rule of thumb is accurate enough that the remaining error is smaller than the file system overhead you have not accounted for yet.

The asymmetry is the part that catches people. Going from GB down to GiB removes 6.87 per cent; going from GiB back up to GB adds 7.37 per cent. Those are the same gap measured against different baselines, and applying the wrong one of the two is how a capacity estimate drifts by half a per cent for no visible reason.

A small number of cases are not a units problem, and they are worth eliminating before the arithmetic is trusted. A partition that does not span the whole disk leaves the remainder unallocated and invisible in the usual view; a partition table in the older format cannot address beyond 2 TiB with standard sector sizes, so a large drive prepared that way silently presents only part of itself.

The distinguishing symptom is that the shortfall is not 6.87 per cent. The unit gap is a fixed proportion and lands on a predictable number; a partitioning problem leaves a round remainder, and a hardware fault shows up in the drive’s own health statistics rather than in its reported capacity at all. Working out which of the three you are looking at takes one comparison against the byte count the drive reports.

Every operating system will show the raw byte count if asked, and that number ends the discussion because it carries no unit convention at all. The Windows properties dialog prints it in parentheses under the friendly size. On Linux, lsblk -b and blockdev --getsize64 report bytes directly; on macOS, diskutil info does the same. Compare that figure against the advertised capacity and the drive is either right or it is not.

What the byte count will show on a healthy drive is a number slightly above the advertised one, because manufacturers round down rather than up. A drive sold as 1 TB typically presents 1,000,204,886,016 bytes, the extra coming from the sector geometry. If the raw count matches the box, every remaining difference is a question about units and file systems, not about the hardware.