Convert KiB to MB

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.

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

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.

A file listed as 24,500 KiB looks like it clears a 25 MB cap with room to spare. It does not: 24,500 KiB is 25,088,000 bytes, and a limit enforced as 25,000,000 rejects it by 88,000 bytes. Nothing in either figure explains the rejection, which is why the usual next step is to try again, then to blame the service, and only much later to check what the two numbers actually mean.

The gap has two components multiplied together. Each kibibyte is 2.4 percent bigger than a kilobyte, and there are a thousand of them per megabyte rather than 1,024, so a KiB figure divided by a thousand understates the file by 2.4 percent throughout. On a small attachment that is a few kilobytes and irrelevant. Within five percent of a hard limit it decides the outcome.

Multiply by 1,024 to get bytes, then divide by a million. 24,500 × 1,024 is 25,088,000, and that is 25.088 MB. In one step it is a multiplication by 0.001024, which is exact and terminates, so there is no rounding anywhere in the arithmetic and any two correct converters will agree exactly. The uncertainty is never in the sum; it is in what the limit at the other end counts.

The check that catches a swapped conversion is the direction of the change. Going from KiB to MB the numeric value must fall by a factor of roughly a thousand, and it must fall slightly less than a factor of a thousand because kibibytes are the larger unit. A result that is exactly a thousandth has dropped the 2.4 percent, and a result that is 1,024 times smaller has converted to MiB instead.

Most consumer services document a limit in MB and check it against a decimal byte count, so 25 MB is 25,000,000 bytes. Some check the binary figure, which is 26,214,400 and 4.9 percent more generous. The documentation rarely says which, and the difference only becomes observable at the moment a file is refused, which is the worst moment to start investigating.

That makes the safe strategy indifference rather than precision. If a file is within five percent of a stated ceiling, it is inside the region where the answer depends on an implementation detail you cannot see, and the right response is to make the file smaller rather than to determine which reading applies. Below about ninety percent of the cap, every plausible interpretation agrees and the question does not need answering.

Email attachments are not sent as bytes. They are encoded into a text-safe form that represents every three bytes as four characters, which adds about 33 percent, and line breaks add a little more. A 20 MB file therefore arrives at the size check as roughly 27 MB of message, and a 25 MB limit on total message size rejects it comfortably.

This is the effect worth internalising, because it is an order of magnitude larger than anything on this page about kilobytes. Where a limit applies to a message rather than to a file, the usable file size is about three quarters of the stated figure. Uploads over the web are usually not affected, since a file sent as form data goes as raw bytes, but anything that travels as mail carries the overhead.

Hosted repositories are stricter than mail because they check programmatically and refuse at the boundary. A platform that warns above 50 MB and refuses above 100 MB is comparing a byte count, and a file listed as 97,000 KiB is 99,328,000 bytes — under the limit, but by less than one percent, which is not a margin to plan around. Large files in a repository also persist in its history, so the check applies to what was ever committed, not to what is present now.

The pattern that avoids the whole category is to keep large binaries out of the place with the ceiling: an artefact store, an object bucket, or a large-file extension that stores a pointer in the repository and the content elsewhere. That is a different decision from converting the number correctly, and it is the one that stops the number needing to be converted repeatedly.

When a file misses by a few percent, the cheapest reductions are usually not compression. Images carry embedded thumbnails, colour profiles and camera metadata that can be several hundred kilobytes; documents accumulate revision history and embedded fonts; archives frequently contain files that are already compressed and gain nothing from being compressed again. Removing what is not needed beats squeezing what is.

If the content itself has to shrink, be aware of what each step costs. Re-encoding a photograph at a lower quality is lossy and cannot be undone; downscaling its dimensions is usually more effective per unit of visible damage; splitting an archive avoids the loss entirely at the cost of a more awkward hand-off. Repeatedly re-compressing an already-compressed file is the one approach that reliably fails, since the second pass has almost nothing left to find. On a file that is a few percent over, removing one embedded asset usually beats every other option, because it is exact, reversible and costs nothing in quality.

A tool that prints KiB has stated its convention and can be trusted. A tool that prints KB has not, and on Windows it almost certainly means 1,024 bytes despite the label. That means the same file can be reported as 24,500 KiB by one tool and 24,500 KB by another, with both figures describing identical bytes and only one of them being honestly labelled.

When precision matters, ask for the byte count instead. Every file manager will show it somewhere, every command line tool will print it, and it removes the question entirely — a byte count needs no interpretation, converts to any unit exactly, and is the number the limit is going to be compared against anyway. Where a workflow repeats — a weekly export, a batch of scans, a set of deliverables going to the same client — recording that byte count once removes the conversion from every future round of it.