Convert MiB to kB

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

The factor is 1048.576, and almost nobody carries that around. Rounded to 1050 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 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.

Build tooling counts in binary units because it is describing what a filesystem holds, and a bundler that prints KiB and MiB has told you so honestly. Performance budgets are written in decimal kilobytes because they describe bytes crossing a network, where powers of ten have been the convention since long before anyone was shipping a megabyte of JavaScript. Both are internally consistent and they do not agree.

The conversion is a multiplication by 1,048.576. A bundle reported as 1.5 MiB is 1,572.9 kB, not 1,536 and not 1,500. Against a 1,500 kB budget it is over by nearly five percent, and the round conversion in somebody's head is exactly what hides that — 1.5 MiB reads as "about one and a half megabytes", which sounds like it fits.

Before worrying about 4.9 percent, check that the number is measuring the right thing at all. A build tool reports the size of the file it wrote; a user waits for the compressed bytes that crossed the connection. Text assets typically compress to somewhere between a fifth and a quarter of their raw size, so a 1.5 MiB bundle may be 350 kB on the wire, and a budget written against the raw figure is off by a factor, not a percentage.

That does not make the unit conversion unnecessary — the compressed figure has to be stated in some unit too, and the same 2.4 percent applies to it. It makes the order of operations clear: establish which stage of the pipeline the number describes, then convert its unit. Getting the second right and the first wrong produces a precisely stated number about the wrong quantity.

A random measurement error averages out over enough assets; a unit error does not, because it is the same multiplication every time and always in the same direction. Every asset appears slightly smaller than it is, the total appears smaller than it is, and every comparison against the budget is slightly optimistic. Nothing in the report looks wrong, and the reconciliation only fails against field data collected by something that measured bytes.

The compounding is what turns it from pedantry into a real gap. A page assembled from twenty assets, each converted with the round factor, is short by 2.4 percent overall — perhaps thirty or forty kilobytes on a moderate page. That is roughly the size of an entire small library, which is the sort of thing teams spend an afternoon removing. The comparison is worth making explicitly when somebody proposes tightening a budget: a correct conversion recovers the same number of kilobytes as a real optimisation, and it takes a line of arithmetic rather than a refactor.

The two will rarely show the same number for the same asset, and the reasons stack. The build report shows raw bytes in binary units; the network panel shows transferred bytes, compressed, in decimal units, and it may or may not include response headers. Any one of those differences is enough to make the figures disagree by tens of percent, and all three together make a direct comparison meaningless.

The way to compare them is to reduce both to a byte count of the same quantity. Take the compressed artefact, read its exact size, and compare that against the transferred size the browser reports; the residual should be small and attributable to protocol overhead. Once those agree, the friendly units on either side can be whatever each tool prefers, because you have a number underneath that both are derived from.

Not everywhere. The bytes that matter most are the ones blocking the first render — the critical CSS, the scripts that must execute before content appears, the fonts that hold text back. Fifty kilobytes there is worth more than five hundred in something loaded lazily after the page is usable, and a budget that treats all bytes as equal will optimise the wrong ones with great precision.

This is also where the unit question stops being academic, because critical-path budgets are the tight ones. A target of 150 kB of blocking JavaScript has almost no headroom; converting a 0.15 MiB figure as if it were 150 kB rather than 157.3 kB has spent five percent of the budget on arithmetic. On a lazily loaded chunk with a budget ten times larger, the same error is invisible and nobody should spend time on it.

A budget is a number somebody else will apply months later without the context you had. That means it needs three things stated with it: the quantity, the unit including which system, and the stage of the pipeline — compressed or raw, per asset or per page. Any of the three left implicit will be filled in by assumption, and the assumption will differ from yours often enough to matter.

The mechanical version is to express the budget in bytes in whatever configuration enforces it, and let the human-readable figure appear in the documentation beside it. Bytes cannot be misread, they compare directly against every tool's underlying measurement, and they remove the need for anyone downstream to know whether the person who set the budget meant 1,000 or 1,024.

Multiply by a thousand and add five percent. 2.4 MiB is roughly 2,400 plus 120, so about 2,520 kB against 2,516.6 exactly. That is accurate enough for a conversation and for spotting an order-of-magnitude mistake, which is what mental arithmetic is for. It is not accurate enough for anything that gets written into a configuration file and enforced.

The threshold for doing it properly is whether the number will be compared against another number. A figure quoted in a discussion can be approximate; a figure that a tool will check, or that will sit in a table next to a measurement from somewhere else, has to be the exact multiplication, because a discrepancy of a few kilobytes in a comparison is indistinguishable from a real regression. That is the practical cost of the shortcut: not a wrong number, but an hour spent investigating a change that never happened.