Convert B to GiB

A byte is eight bits, though that was not always fixed — early machines used six, seven or nine. The eight-bit byte won because it holds one character of text and divides neatly in half.

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.

Going this way is a division, and by a whole number: 1,073,741,824 of these fit into one gibibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a gibibyte, a twelfth of one — rather than as the round figures the other direction gives you.

Nothing is lost to rounding even so. The division is exact, and if your answer will not sit still as a decimal — 0.0833… and friends — that is the fraction showing through, not an error creeping in.

One GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1073741824 B and 1000000000 B — 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 1000000000 B where the box said 1073741824. 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.

Software emits sizes in bytes on purpose. A byte count has no prefix to interpret, no rounding to unwind and no locale in it, so a metrics scrape, a log line and an API response can all be compared without anybody agreeing on what a G means first. That property is exactly what makes the numbers unreadable: 17,179,869,184 conveys nothing until it has been divided by something.

The division to use is 1,073,741,824 when the surrounding system is binary, which for memory, page cache, file system usage and most operating-system counters it is. That figure is 16 GiB exactly. Reaching for a billion instead gives 17.18 and hides the fact that the number was a clean power of two, which is often the most informative thing about it.

Before converting anything, count the digits. Ten of them puts a figure between 0.93 and 9.3 GiB, eleven between 9.3 and 93, twelve between 93 and 931, and thirteen digits lands at around a tebibyte. That single glance answers most of the questions a byte count raises — whether a cache is megabytes or gigabytes, whether a log line reporting a transfer is plausible — without any arithmetic at all.

The habit pays off most in output that mixes scales. A metrics endpoint returning a dozen byte counters will have some in the thousands and some in the billions, and the eye can sort them by length faster than it can parse them by value. Converting only the ones that turn out to matter is considerably quicker than converting all of them.

Certain figures are worth knowing on sight because they identify their own origin. 1,073,741,824 is a gibibyte, 2,147,483,648 is two, 4,294,967,296 is four, 8,589,934,592 is eight, 17,179,869,184 is sixteen. When one of these appears in output it is almost always a capacity or a limit rather than a measurement, because measurements rarely land on exact powers of two.

The converse is equally useful. A byte count ending in a long run of zeros — 1,000,000,000, 50,000,000,000 — was typed by a person or generated from a decimal figure, and it will not correspond to anything the hardware does naturally. Spotting that in a configuration dump often explains why a limit sits slightly below the allocation boundary it was meant to align with.

Languages that store all numbers as double-precision floats hold integers exactly up to 9,007,199,254,740,991, which is 2⁵³ minus one, or about 8 PiB expressed as bytes. Below that ceiling a byte count is safe to carry, compare and add. Above it values round silently, and two different sizes can compare as equal without any error being raised.

Most systems will never reach it, and the ones that do usually meet it in aggregate rather than per object — a total across a fleet, a lifetime transfer counter, a sum over a large table. The defences are to keep byte counts in 64-bit integers or strings across a serialisation boundary, and to do the aggregation where the wide type lives rather than after the number has passed through a layer that widens everything to a float.

Most utilities have a mode that suppresses their human-readable formatting, and it is worth using whenever the output is going anywhere other than a screen. Disk usage tools accept a block size of one, file metadata queries will print the exact length, and object storage APIs return a content length in bytes as a matter of course. All of these are lossless in a way that a formatted 1.4 GiB is not.

The loss is not recoverable afterwards. A figure displayed as 1.4 GiB could be anything from 1,449,551,462 to 1,556,925,644 bytes, a spread of over 100 MB, and no amount of multiplying will narrow it. Pipelines that scrape formatted output and convert it back are building that uncertainty into every downstream number, and the drift only becomes visible when two such pipelines are compared.

The rule that avoids most arguments is to display in the unit the measured system counts in. Memory, page cache, file system usage and buffer pools are binary, so a graph of them belongs in GiB. Object storage totals, egress volumes and anything that appears on an invoice are decimal, so those belong in GB. Converting either into the other on the way to the screen adds a step where a reader can lose track of what they are looking at.

Whichever is chosen, the axis label has to say which one it is. A memory graph labelled GB while plotting a division by 2³⁰ is the same mislabelling that Windows performs, reproduced in a place where somebody will eventually compare it against a decimal figure from a bill. One extra letter on the axis removes the whole class of confusion.

Two tools can both report exact byte counts and still disagree, because they are counting different things. A file length is not the space it occupies, a stored size is not a transferred size once compression is in the path, and a container image size on disk is not the number of bytes pulled over a network. Converting each of them to gibibytes makes them look comparable without making them so.

The discipline that helps is to record what a byte count measures alongside the number itself. A metric named for its unit but not for its subject — bytes, size, total — will eventually be summed with another one that meant something else. Naming the measurement in the label costs nothing and prevents a class of dashboard whose numbers are individually correct and collectively meaningless.

The cheapest verification is to reverse the operation. Take the gibibyte figure, multiply by 1,073,741,824 and compare against the original digit string. If the result is about seven per cent adrift the divisor was a billion rather than 2³⁰; if it is out by a factor of 1,024 a prefix was skipped somewhere. Both mistakes look plausible on a dashboard and neither survives the multiplication.

Where a conversion is embedded in code rather than done by hand, the same check belongs in a test with a known pair: 5,368,709,120 bytes is 5 GiB, and any implementation that produces 5.37 has used the decimal divisor. One assertion of that shape catches the error permanently and costs a line.