Convert KiB to kB

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 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 1.024, and almost nobody carries that around. Rounded to 1.02 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 1.024 kB and 1 kB — 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 1 kB where the box said 1.024. 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.

Every conversion between the binary and decimal scales is some power of 1.024, and this is the only one where the power is one. A figure in KiB becomes a figure in kB by multiplying by 1.024 exactly: 500 KiB is 512 kB, 250 KiB is 256, 1,000 KiB is 1,024. There is no rounding anywhere in that, and the numbers on both sides stay recognisable.

That tidiness is why this pair is the best place to build an intuition for the whole family. The 1,024 that appears on the right-hand side of 1,000 KiB is the same 1,024 that defines the kibibyte, and seeing it come back out of the multiplication makes the relationship concrete in a way that 7.37 per cent at the giga step never does.

The reason to convert in this direction is almost always publication. A tool measured something in KiB, and the figure now has to sit next to numbers that were measured decimally: a competitor’s published page weight, a specification limit, a budget agreed in a document, a table in a report. Leaving it in KiB is defensible and makes the comparison wrong by 2.4 per cent in a way no reader will notice.

The alternative failure is converting silently. A figure that has been adjusted should say so, because the next person to measure it with the original tool will get the original number back and conclude that something regressed. Publishing "174 kB (170 KiB as measured)" costs eleven characters and prevents an afternoon.

Web performance tooling is the commonest place a working developer meets this pair, because two tools in the same browser use different conventions. Lighthouse reports transfer and resource sizes in kibibytes. The network panel reports decimal kilobytes. Run both against one page and the totals differ by 2.4 per cent, consistently, with no bug anywhere.

It is a small enough gap to survive unnoticed until it lands on a threshold. A budget of 170 kB written from one tool and enforced with the other admits or rejects a page at 172 depending on which way round the pair was used, and the resulting investigation goes looking for a resource that changed rather than a unit that did not. Writing the unit into the budget is the whole fix.

The high-density 3.5-inch disk held 2,880 sectors of 512 bytes, which is 1,474,560 bytes: 1,440 KiB, or 1.41 MiB, or 1.47 MB. The number on the label, 1.44, is none of those. It was arrived at by taking the count in binary kilobytes and dividing by a decimal thousand — a hybrid unit that exists nowhere else and that everybody used for twenty years.

It is the clearest surviving evidence that the two conventions were being mixed inside one label long before anybody proposed a fix. The IEC names arrived in 1998 to make exactly this impossible to write down, and the floppy is the example worth keeping because the arithmetic is small enough to check by hand and the result is unambiguously a third thing.

The sources are consistent about the base and inconsistent about the label. ls -lh and du -h print powers of 1,024 under a bare K. free reports kibibytes. /proc/meminfo writes kB and means KiB. Build tooling and bundlers vary, and several report decimal. Lighthouse writes KiB properly.

So the practical question is not which unit a number is in but whether the tool that produced it says. Where it does — KiB, or an explicit --si flag — the conversion is arithmetic. Where it does not, the fastest test is a file of exactly 1,024 bytes: a tool that shows 1.0 is binary, one that shows 1.02 is decimal, and that settles it in less time than reading the manual page.

The kilo step is where the divergence begins and where it is smallest. Two point four per cent is inside the noise of most measurements, comfortably inside the variation between two runs of a page load, and small enough that treating KiB and kB as the same thing is very nearly defensible at this scale.

The reason to be strict anyway is that the habit does not stay at this scale. The same reasoning applied one prefix up is a 4.86 per cent error, two up is 7.37, three up is 9.95, and by then it is a drive. Somebody who is careful about the kilobyte step has already built the reflex that matters at the terabyte one, which is where the same casualness stops being cheap.

Any size that appears in public will eventually be re-measured by somebody with different tooling, and the number that survives that is the one with its unit attached. A page weight, an asset budget, a package size, a payload limit: each is a figure somebody will check, and a 2.4 per cent discrepancy is exactly large enough to look like a regression and exactly small enough to be dismissed as noise, which is the worst combination available.

The convention that works is to publish the decimal figure with the unit spelled out, and to note the measuring tool where it is not obvious. It is not a heavier disclosure than any other measurement carries, and it converts an argument about whose number is right into a five-second check that both are.

Web assets are quoted at three different sizes and only one of them is the one that matters. The uncompressed size is what the file is on disk. The gzipped size is what most servers send. The Brotli size is what modern servers send, typically fifteen to twenty per cent below gzip on text. A JavaScript bundle described as 300 kB may be 90 gzipped and 78 with Brotli, and all three figures are true.

So a published figure needs two labels rather than one: the compression and the unit. "78 kB Brotli" is a claim somebody can check; "78 KiB" alone leaves them 2.4 per cent adrift, and a bare "78 kB" leaves them wondering which of three measurements it was. Given how often these numbers appear in comparisons between tools and frameworks, the labelling is doing more work than the last digit of the value.