Convert MB to KiB

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 kibibyte is exactly 1,024 bytes. The name was coined in 1998 precisely so that "kilobyte" could go back to meaning 1,000, though the habit never fully took.

The factor is 976.5625, and almost nobody carries that around. Rounded to 980 it is off by 0.35 % — 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 KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 0.001 MB and 0.001 MB — 2.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 2.4 %. A drive sold in kB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0.001 MB 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.

Requirements arrive in round decimal numbers because that is how people write them: a 100 MB upload cap, a 500 MB per-user quota, a 2 MB rate limit. The field that enforces them frequently counts in kibibytes, so the round number has to be divided by 1,024 before it can be typed, and it stops being round on the way. 100 MB is 97,656.25 KiB, and the field will not take the quarter.

That is the whole job of this conversion: turn a human figure into a block count, then decide what to do with what is left over. Multiply megabytes by 976.5625 and the result is exact to four decimal places at most, because 1,000,000 divided by 1,024 terminates. The remainder is always some multiple of a sixteenth of a kibibyte, which is 64 bytes, and it is the only part of the calculation that needs judgement.

Most values in this direction leave a fraction, and the ones that do not follow a rule. A megabyte is 15,625 sixteenths of a kibibyte, so any megabyte figure that is a multiple of 16 comes out whole: 16 MB is exactly 15,625 KiB, 512 MB is exactly 500,000 KiB, and 1,024 MB is exactly 1,000,000 KiB. Every power-of-two limit from 16 MB upwards is therefore exact, and it is the round decimal figures — 100 MB, 250 MB, 500 MB — that leave a remainder.

That makes 512 and its multiples the values to reach for when a limit is arbitrary anyway. A quota set at 512 MB, 1,024 MB or 2,048 MB converts to a clean block count, records the same way in both units, and avoids the small permanent discrepancy between what the policy document says and what the system enforces. Where the number has to be 500 rather than 512, the conversion is 488,281.25 KiB and something has to give.

The high-density 3.5-inch disk held 1,474,560 bytes: eighty tracks, two sides, eighteen sectors of 512 bytes. That is 1,440 kibibytes exactly, and the marketing figure was produced by dividing 1,440 by 1,000 and writing MB after it. The result is not 1.44 megabytes, which would be 1,440,000 bytes, and not 1.44 mebibytes, which would be 1,509,949.

The unit behind that number was thousands of 1,024-byte blocks, a hybrid nobody ever named and nobody has used since. It is worth knowing because it is the clearest evidence that the two conventions were not merely confused but occasionally combined, and because it explains why a disk everyone remembers as 1.44 MB always came up short when a file of that size was copied to it.

Shell stack and virtual memory limits are in kibibytes, so a 512 MB virtual memory ceiling is entered as 500,000. Disk quota tools allocate in blocks of the same size, which is why a quota report shows six-digit numbers where a person was thinking in megabytes. Several file synchronisation tools take a transfer rate cap in kibibytes per second unless a suffix says otherwise, so a bare 1000 there means 1,024,000 bytes per second rather than a megabyte.

None of these announce the unit in their normal output, and neighbouring options within a single tool do not always agree. Checking the documentation for the specific setting takes less time than diagnosing a limit that is out by a factor of 1.024 or, worse, by a factor of two because a different block size was involved. The check is worth doing once per setting and writing down.

Round down when the number is a ceiling and up when it is an allowance. A 100 MB cap entered as 97,656 blocks permits 99,999,744 bytes, which is inside the policy; entered as 97,657 it permits 100,000,768, which is outside it by 768 bytes. Neither figure will cause a problem on its own, but only one of them can be defended if somebody audits the setting against the policy that produced it.

The direction matters more when the same conversion is applied repeatedly. A quota system that rounds every allocation up gives away a fraction of a block per account, and across a large user base that is real capacity assigned to nobody in particular. Deciding the rounding rule once, at the point where the policy is translated, keeps every derived number consistent with the one before it.

A requirement written in megabytes has often already been through a binary tool. If the 100 MB figure came from somebody reading a file manager, it is likely to be 104,857,600 bytes rather than 100,000,000, and converting it as decimal produces a limit five per cent tighter than intended. The tell is where the number came from rather than how it is written.

Asking is cheaper than assuming, and where nobody can answer, the safe reading depends on which failure is worse. If the limit protects a resource, take the decimal reading and set the smaller value. If it promises capacity to a user, take the binary reading and set the larger. Recording which assumption was made, beside the setting, saves the next person from re-deriving it differently.

The reverse trip is the one that gets done in a hurry, usually while somebody is asking why a user has run out of space. A quota report showing 488,281 blocks is 500 MB, and a report showing 512,000 is 524.29 MB — close enough to each other that the two are easy to confuse and far enough apart to matter to whoever is at the limit.

Dividing the block count by 976.5625 gives megabytes, and dividing by 1,024 gives mebibytes. Doing both takes a moment and immediately shows which unit the limit was set in: the one that produces a round number is almost always the one somebody typed. That single observation resolves most disputes about whether a quota was configured as intended.

Limits expressed as awkward block counts tend to sit slightly across a boundary that matters. File systems allocate in blocks of 4,096 bytes and memory in pages of the same size, so the 97,656.25 KiB that 100 MB converts to is 24,414 pages of 4 KiB plus a quarter of a kibibyte that no allocation can use. Nothing breaks, but the effective limit ends up a little under the configured one.

Choosing limits that are multiples of 4 KiB removes that residue, and choosing them as multiples of 512 MB removes both the residue and the fractional conversion at once. Where a policy allows any round-ish number, picking one that is round in both systems costs nothing and means the figure in the ticket, the figure in the config and the figure the kernel enforces are all the same number.