Convert B to MiB

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 mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

Going this way is a division, and by a whole number: 1,048,576 of these fit into one mebibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a mebibyte, 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 MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 1048576 B and 1000000 B — 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 1000000 B where the box said 1048576. 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 byte count is the reliable number in this exchange. It comes out of a filesystem call or a content-length header, it has no unit ambiguity, and it is what the software will eventually compare against. The MiB figure is a human convenience layered on top of it, and every problem in this direction comes from treating the convenience as the source of truth and letting the exact number be reconstructed from it.

So do the conversion in the order that keeps the byte count authoritative: divide by 1,048,576, decide what to round to, and then multiply back to confirm the limit you have written still admits the file you measured. That last step takes seconds and catches the whole class of errors this page exists for, because a limit is not correct when it looks right, it is correct when the file passes it.

A file of 10,486,000 bytes is 10.0002 MiB. Written into an upload cap as "10m" it is now larger than the limit and will be refused, and the error message will say the file is too big for a limit the operator believed was exactly its size. Rounding down is the default habit, and for an upper bound it is always the wrong one — the bound has to be at least the largest thing it is meant to admit.

The mirror case is a reservation rather than a cap. Space set aside for a cache, a log buffer or a preallocated file must round down, because rounding up promises capacity that is not there and the shortfall appears later, under load, as a write failure. One question decides the direction every time: if this number is wrong by a byte, would I rather have slightly too much or slightly too little?

A great deal of configuration accepts a suffix, and the suffix rarely says which system it belongs to. nginx reads k as 1,024 and m as 1,048,576, so client_max_body_size 10m is 10,485,760 bytes. The JVM does the same with -Xmx and -Xms. GNU dd splits the difference explicitly: bs=1M is 1,048,576 while bs=1MB is 1,000,000, and the two produce different files from the same command.

Kubernetes is the one worth learning from, because it refuses to guess. Mi, Gi and Ti are the binary quantities and M, G and T are the decimal ones, both are valid in a manifest, and a memory limit of 512M is 4.6 percent smaller than one of 512Mi. Nothing warns you: the manifest applies, the pod starts, and the limit is not where it was meant to be.

A mebibyte is 2 to the twentieth, and that is why it turns up as the natural size for things a kernel allocates. Pages are 4 KiB, huge pages are commonly 2 MiB, and a buffer sized to a power of two aligns with all of them without leaving a remainder at the end. Choosing 1,000,000 bytes for the same buffer is not wrong, it is a number the allocator underneath has to round up anyway, so the alignment is bought back at a lower level or paid for in a partial page.

The practical consequence is that binary-sized values propagate. If your block size is a power of two, and your part size is a multiple of your block size, and your limit is a multiple of your part size, everything divides exactly and no stage has a partial unit at the end. Introduce one decimal figure into that chain and every stage below it starts producing remainders, which is a small inefficiency and a large source of off-by-one confusion.

Uploading a large object in parts is where these numbers stop being cosmetic. A part size chosen in binary units divides a file into a whole number of full parts plus a remainder, and the count of parts is capped, so the part size has to be large enough that the object fits within the cap. Working that out from a rounded MiB figure rather than the byte count is how an upload fails at part 10,001 after transferring most of the file.

The check is arithmetic and worth doing before the transfer rather than during it. Divide the exact object size in bytes by the part size in bytes, round up, and confirm the result is inside the provider's limit. If it is close, increase the part size rather than hoping; the failure is at the end of a long upload, and by that point the useful diagnostic information is a number you could have computed in advance.

Displaying 10.5 MiB is fine. Storing 10.5 MiB and later reconstructing the byte count is not, because the display has thrown away everything below about a thousand bytes and there is no way to recover it. Manifests, checksum listings and audit records should carry the byte count and derive the friendly figure at the moment of display, in that order, so that the exact number survives every round trip through a report.

The same rule applies to comparisons. Two objects both shown as 4.2 MiB may differ by fifty thousand bytes, and a deduplication or drift check written against the displayed value will call them identical. Anything that decides equality — sync, backup verification, cache validation — compares byte counts, and the MiB figure appears afterwards for the benefit of whoever reads the log.

The costliest mistake available on this page is not the 4.9 percent between MB and MiB, it is the factor of eight between bytes and bits. Storage and file sizes are counted in bytes; throughput is quoted in bits per second, which is why a 100 Mb/s connection delivers 12.5 MB/s at best and why a download of a 500 MiB file over it takes about forty seconds rather than five.

The convention that distinguishes them is a capital B for bytes and a lowercase b for bits, and it is followed often enough to rely on and violated often enough to check. When a figure looks eight times larger or smaller than it should, that is the first thing to test, before any question about which thousand somebody meant. It is worth checking on any figure copied out of a network diagram or a vendor specification sheet, where bits are the house unit and bytes are the exception.