Convert kB to MiB

A kilobyte is 1,000 bytes when a standards body defines it and 1,024 when an operating system does. This page uses 1,000; the kibibyte is the unit that means 1,024.

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

The factor is 0.000954, and almost nobody carries that around. Rounded to 0.00095 it is off by 0.39 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 kB.

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 1048.576 kB and 1000 kB — 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 1000 kB where the box said 1048.576. 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 front-end project holds both conventions at once and rarely says so. The network panel reports transfer sizes in kilobytes of 1,000 bytes, performance guidance is written the same way, and CDN billing counts decimal gigabytes because that is how bandwidth has always been sold. Meanwhile the build tool, the proxy cache and the browser storage quota underneath them all count in powers of 1,024.

The conversion between the two crosses a prefix step and the decimal-to-binary line together, so it divides by 1,048.576 rather than by a thousand. On a 3,000 kB bundle that is the difference between 3.00 and 2.86, and the smaller figure is the true one. Checking a binary limit with the decimal shortcut always reports more headroom than exists, which is the wrong direction for a check to be wrong in.

The numbers worth having: 500 kB is 0.4768 MiB, 1,000 kB is 0.9537, 2,000 kB is 1.9073 and 5,000 kB is 4.7684. A page that a network panel totals at 2,090 kB has not crossed a 2 MiB budget, because 2 MiB is 2,097.152 kB — but it is within seven kilobytes of doing so, and a decimal reading against a 2 MB line would have declared it over ninety kilobytes ago.

The gap runs the other way for a limit stated in binary and read as decimal. A cache configured at 50 MiB holds 52,428.8 kB of assets, not 50,000, and a capacity plan built on the round figure leaves nearly two and a half megabytes of the cache unused. Neither error is large, and both are systematic, which means they accumulate in the same direction every time the calculation is repeated.

Before arguing about 4.9 per cent it is worth settling which size is being measured. A text bundle typically compresses to a third of its uncompressed length or less, so the same file can honestly be described as 900 kB or 260 kB depending on whether the figure is what the build produced or what crossed the network. That is a factor of three, against a units question worth five per cent.

Budgets should therefore name the state as well as the unit: transferred, compressed, or raw on disk. Build tools generally report uncompressed asset sizes because that is what they have, and browser panels report transferred bytes because that is what they observed. A limit that does not say which one it governs will be enforced against whichever the tool happened to have, and the two are not comparable.

Several bundlers accept asset size limits as plain byte counts, and using that form means no prefix has to be agreed on. A limit of 250,000 bytes is unambiguous, greps cleanly, and is directly comparable against the byte counts the same tool reports. A limit written 250 kB is the same intent with a footnote attached, and the footnote is the part that gets lost when the configuration is copied into another project.

Where the tool insists on a prefix, prefer the binary one and write it explicitly. A cache limit of 50m in a proxy configuration is 52,428,800 bytes whatever the reader assumed, and writing MiB in the comment beside it costs one line. The alternative is a limit that everybody believes is 50 million bytes and that is in fact almost two and a half million larger.

Performance budgets exist to catch small, steady growth, and the size of the gap they are looking for is often the same size as this units error. A bundle growing by four per cent a release is exactly the kind of drift a budget should flag, and it is exactly the amount a decimal-versus-binary mismatch will absorb before anybody notices. One release of unexplained slack is enough to hide a full quarter of growth.

The fix is to make the reported number and the limit come from the same source. If the build tool measures in bytes, set the budget in bytes; if the monitoring measures transferred kilobytes, set the budget in transferred kilobytes. Every conversion between the report and the threshold is a place where a systematic offset can settle in and stay.

Client-side storage — caches, databases, persisted state — is measured against a quota the browser calculates from available disk, and the byte counts it reports are exact rather than prefixed. Asking the storage estimate for its numbers gives usage and quota in bytes, which is the form to compare against, and converting them to mebibytes for display is a presentation choice made afterwards.

The reason to keep the raw bytes is that quotas move. They depend on free disk, on the origin’s storage class, and on browser policy, so a value that was 500 MiB last week may not be this week. Code that stores the byte count and re-checks it will behave correctly through those changes; code that hard-codes a converted figure in a friendlier unit will not.

The SI symbol for kilo is a lowercase k, so a decimal kilobyte is correctly written kB. The binary unit takes a capital: KiB, with the capital K chosen deliberately because the lowercase one was already taken. That leaves KB, with a capital K and no i, as the form that belongs to neither standard and is used constantly, usually meaning 1,024.

The spelling is therefore a weak signal rather than a rule. A document that writes kB and MB consistently, with the correct casing throughout, was probably written by somebody who knows the difference and means decimal. One that writes KB is following a much older habit and most likely means 1,024. Neither observation is strong enough to act on alone, but both are worth noticing before assuming which convention a figure came from.

Divide by a thousand, then take five per cent off. A total of 4,400 kB becomes 4.4 and then about 4.18 MiB, against 4.1962 exactly — close enough to know instantly whether a 4 MiB ceiling has been crossed. For anything up to a few megabytes the estimate is within a couple of kilobytes of the true figure.

Going the other way, multiply by a thousand and add five per cent: a 10 MiB limit is about 10,500 kB, against 10,485.76. The two shortcuts are not symmetrical, since one takes 4.86 per cent off and the other adds it back onto a smaller base, but at this scale the difference between the two corrections is a few kilobytes and well inside the noise of any real measurement.