Convert MiB to GB

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

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

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

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 MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 0.001 GB and 0.001 GB — 4.9 % — 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 4.9 %. A drive sold in MB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0.001 GB where the box said 0.001. 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 two numbers in this comparison come from opposite worlds. The usage figure is produced by a device counting bytes for its own purposes, and devices count in powers of 1,024, so per-app usage, downloads and file sizes are displayed in mebibytes whatever letter follows them. The allowance is a commercial figure — a plan, a tier, a printed capacity — and commercial figures are decimal.

That means the comparison people make most often, glancing at one number and remembering the other, is systematically wrong by 4.86 per cent in the direction of comfort. A total of 4,800 shown against a cap of 5,000 looks like four per cent of room remaining and is in fact 0.7 per cent over. The units are close enough in name to invite the comparison and far enough apart to spoil it.

The multiplication most pages give is 1,000 MiB to 1.049 GB, and the division is more useful for this reader: 953.67 MiB fills one gigabyte. Five gigabytes is 4,768 MiB. Ten is 9,537. Twenty is 19,073. Those are the ceilings to compare a device reading against, and each is a few per cent lower than the round number anybody would assume.

The rough version is to knock five per cent off the allowance before comparing. A 5 GB cap behaves like 4,750 on a screen that shows mebibytes; a 50 GB plan behaves like 47,500. That is close enough for a decision and easy enough to do while looking at a phone, which is the situation this conversion is usually needed in.

It would be neat if applying 1.048576 made a device’s figure match a provider’s, and it does not. Providers count at a different point: their meter sees protocol headers, retransmissions and connection setup that the device attributes to nothing. Many round each session up to a billing increment, so a hundred short sessions cost more than one long one carrying the same payload. Some exclude their own services from the count and some do not.

So the conversion answers a narrower question than it appears to. It tells you what your own total means in the provider’s units; it does not tell you what the provider recorded. Where the two are within a few per cent after converting, the difference is measurement. Where they are twenty per cent apart, something else is going on and no unit arithmetic will find it.

Storage sold by capacity carries the identical structure one prefix higher. A card labelled 64 GB holds about 64,000,000,000 bytes and reports as roughly 59.6 in a device counting binary — a 7.37 per cent gap rather than 4.86, because the giga step is one further along. A 128 GB stick shows around 119. Neither has been mis-sold.

Cloud storage plans behave the same way and add a second subtraction. The quota is decimal, the client displays binary, and the provider often counts object metadata and versions against the total as well. The order that avoids surprises is to convert first and then ask what else is being counted, because those are two separate questions and only the first has an exact answer.

Where the total comes from adding many displayed figures, the rounding does more damage than the units. A list of two hundred files each shown to one decimal place in MiB carries up to 0.05 MiB of rounding apiece, so the sum can be ten mebibytes out before any conversion happens. That is larger than the 4.86 per cent correction on a small total and it is invisible.

The fix is the same as everywhere else in this category: total the bytes if the bytes are available, and convert once. Where only the displayed figures exist, treat the answer as approximate and say so, rather than converting a sum of rounded numbers to three decimal places and presenting the result as if it were measured.

Ignoring the distinction is not a symmetric mistake. Reading a mebibyte figure as though it were a megabyte under-states the quantity, and reading a decimal allowance as though it were binary over-states the room available. Both errors point the same way, and they compound when a reader makes both at once, which is the ordinary case.

A total of 9,000 MiB against a 10 GB plan looks like a tenth of the plan spare and is 9.44 GB, leaving 0.56. That is the shape of the whole problem: the numbers are close enough to compare directly, the comparison is always optimistic, and the correction is never large enough to be obvious in hindsight.

Very few consumer interfaces write MiB. They write MB and compute in mebibytes, which is a labelling convention inherited from decades of operating systems doing the same. There is rarely a setting to change it and rarely any documentation stating it, so the reader is left to infer the base from context.

The reliable inference is the capacity itself. If a device with a 64 GB card reports its total storage as about 59.6, it counts in binary and every other figure on the screen does too. If it reports 64.0, it counts decimally and no conversion is needed. One reading of one number settles how to interpret everything else the device will ever show you.

The largest single item in most people's usage is video, and video sizes are governed by a bit rate rather than by anything visible. An hour of streaming at 5 Mbit/s is 18,000,000,000 bits, which is 2.25 GB, or about 2,146 MiB. At 3 Mbit/s the same hour is 1.35 GB; at 8 Mbit/s it is 3.6 GB. Quality settings move that figure by more than any conversion on this page ever will.

It is also the place where the bit and the byte are most easily confused, and the confusion is a factor of eight rather than a few per cent. A rate written Mb/s is megabits and one written MB/s is megabytes. Where an allowance is being planned around video, establishing the bit rate and dividing by eight is the step that determines the answer; the decimal-versus-binary correction afterwards is a refinement on top of it.