Convert MiB to MB

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 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.

The factor is 1.048576, and almost nobody carries that around. Rounded to 1.05 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 1.0486 MB and 1 MB — 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 1 MB where the box said 1.0486. 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 come from different places and neither mentions the other’s convention. Your file manager, archiver or image tool divides by 1,048,576 and shows mebibytes, sometimes labelled MB. The service you are uploading to publishes a limit in megabytes and usually enforces it against a raw byte count. Between them sits 4.86 per cent, which is invisible on a 3 MiB file and decisive on a 24 MiB one.

Working out which side of a limit a file falls on takes one multiplication: mebibytes times 1.048576. A 20 MiB attachment is 20.97 MB and clears a 25 MB cap. A 24 MiB attachment is 25.17 MB and does not, by 165,824 bytes. The rejection message will say the file is too large and will not say that the size shown to you was measured in a different unit from the size that was checked.

A memory module holds a power of two bytes because it is addressed through binary address lines, and no manufacturer has ever had a reason to build one that does not. A stick sold as 8 GB contains 8,589,934,592 bytes — 8 GiB — and the label is loose while the hardware is exact. Memory reporting tools follow the hardware, so a figure from one of them is in mebibytes whatever the column heading says.

Storage has no such constraint, and drives have been specified in decimal units for as long as they have been sold. That is how a single machine carries both conventions in one specification: 16 GB of memory that is really 17.18 decimal gigabytes, and a 512 GB drive that is really 476.84 GiB. Reading one spec sheet with a single conversion rule produces two wrong numbers rather than one.

A size only needs converting when it is about to cross into somebody else’s system of units. Telling a colleague that a build artefact is 340 MiB is fine if they will read it with the same tools. Putting 340 in a field labelled MB is a claim that it is 340,000,000 bytes when it is 356,515,840, and the difference propagates into whatever is planned on the basis of it.

The figures that recur are worth carrying: 100 MiB is 104.86 MB, 250 MiB is 262.14, 500 MiB is 524.29 and 1,024 MiB is 1,073.74, which is a gibibyte and the point at which most people switch prefix. An installer described as 500 MB and measured at 500 MiB is 24 MB larger than advertised, which is the kind of small discrepancy that gets reported as a packaging bug.

Attachment caps, upload ceilings and package size rules are almost always written as a plain number of MB, and the documentation seldom defines the unit. The enforcement, though, is done against a byte count in code, so there is a definite answer even where the prose is ambiguous. The practical approach is to assume the stricter reading — a decimal megabyte — and leave a margin rather than testing the boundary with something that matters.

Where the limit can be probed cheaply, probing settles it. Upload a file of known byte length a little under each candidate threshold and see which is refused. That takes two attempts and produces a number you can rely on afterwards, which is better than a series of rejected uploads whose sizes were only ever known approximately.

A size displayed to one decimal place has already lost enough precision to hide a limit breach. A file shown as 25.0 MB might be 24,950,000 bytes or 25,049,000, and only one of those passes a 25 MB check. Adding the unit conversion on top of that rounding compounds two uncertainties that each look small and together span a couple of hundred thousand bytes.

The rule that survives contact with real limits is to stop rounding before the comparison rather than after it. Take the exact byte count, express the limit in bytes under the interpretation you are assuming, and compare integers. Display the friendly figure afterwards for the benefit of whoever reads the result, by which point the decision has already been made on exact numbers.

Optical media carry capacities that were quoted decimally and are stored binarily, which makes their sizes look wrong from both directions. A disc image sized to fill a single-layer DVD is 4,700,372,992 bytes: that is 4.7 GB exactly as the packaging says, and 4,482.6 MiB as an authoring tool will report it. Neither figure is a round number in the other convention and neither is an error.

The same shape appears in any container whose size was designed against a decimal specification and is being measured by a binary tool. If a target capacity is quoted in decimal units, convert the content to decimal before deciding whether it fits. Comparing a mebibyte measurement against a megabyte capacity leaves you about five per cent of the disc in error, which on a DVD is over 200 MB of content that will not be written.

Network operators sell data in decimal units, as the whole telecommunications industry always has, so an allowance quoted in megabytes or gigabytes means powers of a thousand. A download that a phone reports as 100 MiB consumes 104.86 MB of that allowance, and the 4.86 per cent is charged whether or not the handset displays it in the same unit it was sold in.

The gap is small enough to ignore on a single download and not on a metered connection over a month. Ten gibibytes of usage is 10.74 GB against the allowance, so a plan sold as 10 GB is exhausted before a device reporting binary units shows ten of anything. That is the ordinary explanation for an allowance that seems to run out early, and it is arithmetic rather than anybody miscounting.

When two tools disagree about the size of one file, the byte count resolves it in a single step and almost always shows that both were right. A file of 356,515,840 bytes is 340 MiB and 356.52 MB, and a screenshot of one number next to a screenshot of the other looks like a contradiction until the third number is produced.

Keeping the byte count in anything that will be read later — a ticket, a manifest, a build log — costs a few characters and removes the whole question from future conversations. It also makes the record machine-comparable, which the formatted size never is: nothing can be automated on a value that has been rounded for display and labelled with a prefix that two systems define differently.