Convert MB to GiB

A megabyte is a million bytes. Storage manufacturers have always used this decimal meaning, which is why their capacities look larger than what a computer reports.

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.000931, and almost nobody carries that around. Rounded to 0.00093 it is off by 0.14 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 MB.

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 1073.7418 MB and 1000 MB — 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 1000 MB where the box said 1073.7418. 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.

Files come with decimal labels: a download listed at 700 MB, a video at 1,400 MB, a catalogue that adds up to 18,000 MB. Containers come with binary ones: a partition of 20 GiB, an image of 8 GiB, a quota expressed the way the filesystem counts. The question of whether one goes into the other is a single multiplication by 0.000931322574615478515625, and it is exact.

18,000 MB is 16.76 GiB, so it fits a 20 GiB volume with room left. The habit that goes wrong is dividing by 1,000 and calling it 18 GiB, which in this direction is merely pessimistic — the pile looks larger than it is. The same habit applied to the reverse question, sizing a volume for a known amount of decimal-labelled content, leaves you 7 percent short.

This pair crosses two steps between the systems rather than one, which is why the number is unfamiliar. One step is 1,024 against 1,000 and gives 2.4 percent; two steps give 4.9; three, which is what MB to GiB spans, give 7.4 percent read one way and 6.9 read the other. A megabyte-to-gibibyte figure is 93.1 percent of the naive division, and 0.931 is the constant worth recognising on sight.

Its counterpart is 1.074, which is what you multiply by going the other way. Between them those two numbers explain almost every storage discrepancy at this scale: if a figure is out by about 7 percent, one side of the comparison crossed three steps of the ladder in the wrong system, and no further investigation is needed.

The single-layer DVD is the clearest everyday example because both numbers are printed where people can see them. The disc holds 4,700,000,000 bytes, which is 4.7 GB by the standard definition and is what the packaging says. Windows divides by 1,073,741,824, gets 4.377, and labels it GB — so the same disc is 4.7 GB on the box and 4.37 GB on the screen with nothing lost in between.

That is why a disc image assembled to fill "4.7 GB" using a tool that counts in binary units will not burn: the tool thinks it has 4.7 of its own gigabytes to fill, which would be 5.05 billion bytes, and the disc has 4.7 billion. Authoring software that gets this right works in bytes throughout, and the ones that got it wrong are why the problem was so familiar for so long.

The conversion tells you whether the bytes fit; it does not tell you whether the files fit, and those are different questions. A filesystem reserves space for its own metadata, and more importantly it stores every file in whole blocks — typically 4 KiB — so a 100-byte file occupies 4,096 bytes and a 5,000-byte file occupies 8,192. The sum of file sizes is therefore always an underestimate of the space they will take.

How much of an underestimate depends entirely on the file mix. A few large media files lose almost nothing, since only the last block of each is partly empty. Tens of thousands of small files can lose a substantial fraction: a hundred thousand files averaging 1 KB occupy about 400 MB rather than 100. When a container is being filled to within a few percent, the file count matters as much as the total.

Virtualisation tools generally create disks in binary units and interfaces frequently display the decimal reading of the result, which is why the sizes look untidy. A disk created as 20 GiB is 21,474,836,480 bytes and shows as 21.5 GB; a disk created as 20 GB is 18.6 GiB. Both exist, both are legitimate, and a plan that assumes they are the same size is out by a drive's worth on a large host.

The practical approach is to decide the capacity in bytes, create the disk in whichever unit the tool offers, and then verify the byte count rather than the label. Thin-provisioned disks add a second consideration: the logical size is what the guest sees and the physical file grows towards it, so a host can be oversubscribed by a large margin without any single number in the interface looking wrong.

Work out the total in bytes, add the block-rounding for the expected file count, add the filesystem overhead, then convert to whatever unit the creation dialog wants. Doing it in that order means each allowance is applied to a number in a known unit, and the conversion happens exactly once at the end where it can be checked. Doing it in any other order mixes an allowance in one system with a total in another.

Then leave real headroom, because a container that is technically large enough is a bad place to be. Filesystems slow down and fragment as they approach full, some need free space to complete operations at all, and any growth in the content requires the whole exercise to be repeated. Ten to twenty percent spare removes an entire category of future work for a cost that is usually trivial. The exception is a container whose size is fixed by something physical, such as an optical disc, where there is no headroom to buy and the only remaining lever is what goes in.

Divide by a thousand and take off seven percent. 4,700 MB is 4.7 minus about 0.33, which is 4.37 GiB against 4.3772 exactly. 18,000 MB is 18 minus 1.26, which is 16.74 against 16.76. The estimate is good to a fraction of a percent across the whole range this pair is used in, which is enough for a decision about whether something fits with room to spare.

It is not enough for a decision at the margin, and the margin is where people reach for it. If the total is within a few percent of the container, do the exact arithmetic and account for the block rounding as well, because at that point the estimate and the reality differ by about as much as the headroom you have left. The exact figure takes a few seconds and the alternative is discovering the shortfall at the end of a copy that has already run for an hour.