Convert KiB to B

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 byte is eight bits, though that was not always fixed — early machines used six, seven or nine. The eight-bit byte won because it holds one character of text and divides neatly in half.

Going this way is a multiplication, and by a whole number: one kibibyte is 1,024 bytes, exactly, and 1,024 is the definition rather than a measurement that came close.

That makes it one of the few conversions worth doing in your head, and it makes the answer checkable: divide back and you must land on the number you started with, exactly, with no remainder to explain away.

One KiB is 1,024 of the unit below it; one kB is 1,000. On this page that is the difference between 1024 B and 1000 B — 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 1000 B where the box said 1024. 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.

The arithmetic is the least of it: multiply by 1,024 and the byte count is exact. What makes the conversion worth a page is that the source figure arrives under half a dozen different labels. Kernel interfaces print kB and mean kibibytes. Tools invoked with a k flag report in kibibytes and say nothing. Documentation written after 1998 says KiB and means it. All three describe the same 1,024-byte unit.

That leaves the reader doing an identification step before the multiplication. The reliable test is the tool rather than the label: anything reporting memory or block usage on a Unix-like system is counting in units of 1,024 unless it has been explicitly asked for SI units. Anything quoting a file size to a human — a download page, an upload limit, a network transfer figure — is more likely to mean a thousand.

A file’s stored block count is expressed in 512-byte units, and it has been since the interface was defined, regardless of what the file system underneath actually allocates in. A file occupying one 4,096-byte block therefore reports eight blocks. The same file under du -k reports 4, because that tool counts in kibibytes. Neither figure is wrong and neither can be compared to the other without knowing which block each one means.

The practical rule is to convert everything to bytes before comparing anything. Eight 512-byte blocks and four kibibytes are both 4,096 bytes, and the agreement is invisible until both are expressed that way. Scripts that compare a stored block count against a kibibyte total without normalising are out by a factor of two, and the error is stable enough to look like a real discrepancy rather than a bug.

Two different questions hide behind the word size. The length of a file is the number of bytes it contains; the space it occupies is the number of allocated blocks multiplied by the block size. For a 100-byte configuration file those are 100 bytes and 4,096 bytes, a difference of forty times, and each is the right answer to a different question.

The gap runs both ways. A sparse file — one with unwritten regions that were never allocated — reports a length far larger than the blocks it holds, which is why a virtual disk image can list as 40 GiB and occupy 3. Converting a kibibyte block total to bytes tells you what the storage is carrying; converting a length tells you what a copy of the file will produce. Backup estimates that use the wrong one of those are wrong by whatever the sparseness happens to be.

Shell resource limits mix their units and the mixture is not obvious from the output. The stack size limit and the virtual memory limit are in kibibytes, so a stack limit reading 8192 is 8,388,608 bytes. The file size limit is in 512-byte blocks by default. Reading a set of limits as though they shared a unit produces a memory ceiling that is out by a factor of two in one direction or the other.

The reason to convert them at all is usually that something else is expressed in bytes. A process that fails with a memory error reports the allocation it attempted in bytes; matching that against a limit reported in kibibytes takes one multiplication and turns a guess into an answer. Where the limit turns out to be nowhere near the failing allocation, the cause is elsewhere, and knowing that quickly is worth the arithmetic.

Below a certain granularity the byte count stops being the useful number. Memory is handed out in pages, and on most systems a page is 4,096 bytes. File systems allocate in blocks, and the common default is the same figure. Drives with the newer sector format present 4,096-byte sectors. The layers stack neatly because they all chose the same power of two, and a size that is a multiple of it passes through all of them without waste.

That alignment is why buffer sizes, cache entries and record lengths cluster on multiples of 4,096. A read of 4,000 bytes touches the same page as a read of 4,096 and costs the same; a record of 4,100 bytes spans two blocks and costs twice the writes it appears to need. Converting a kibibyte figure to bytes is often the first step in checking whether a size sits on that boundary or a little past it.

At this scale the difference between a kilobyte and a kibibyte is 24 bytes, and for most purposes it disappears into rounding. A page weight quoted as 500 kB is not meaningfully different from 500 KiB, and arguing about the distinction on a single file is time poorly spent.

It becomes material when it is multiplied. A million records of 4 KiB each is 4,096,000,000 bytes, not 4,000,000,000, and a capacity plan built on the second figure is 96 MB short before anything unexpected happens. The same applies to per-request accounting, quota calculations and anything else where a small unit is counted a large number of times: the gap does not grow, but the count it is multiplied by does.

Not every k is 1,024, and assuming otherwise is its own error. Network throughput, transfer allowances, storage capacities and anything printed on packaging are decimal, so a kilobyte in those contexts is 1,000 bytes and multiplying by 1,024 overstates the result by 2.4 per cent. The same reader who has learned to distrust a k in shell output has to remember to trust it on an invoice.

The rule that covers both without much thought: if the number describes what a machine is doing internally, it is binary; if it describes what is being sold, transferred or advertised, it is decimal. That heuristic is not perfect, but the exceptions announce themselves — a tool that means 1,000 usually has a flag saying so, and one that means 1,024 usually has documentation that admits it.

Byte counts stay exact in any integer type wide enough to hold them, and a kibibyte figure multiplied by 1,024 stays exact too. Trouble starts when a value has already been rounded for display: a tool printing 1.4 KiB has thrown away the byte count, and multiplying the rounded figure back gives something between 1,382 and 1,485. Recovering the original is not possible, so take the byte count from the source rather than from the summary wherever both exist.

Most tools will produce raw bytes on request, and that output is the one to feed into anything automated. Human-readable formatting is a display choice made at the last moment, and treating it as data is how a monitoring pipeline ends up with sizes that drift by a few per cent for no reason anybody can find later.