Convert B to KiB

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.

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.

Going this way is a division, and by a whole number: 1,024 of these fit into one kibibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a kibibyte, a twelfth of one — rather than as the round figures the other direction gives you.

Nothing is lost to rounding even so. The division is exact, and if your answer will not sit still as a decimal — 0.0833… and friends — that is the fraction showing through, not an error creeping in.

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.

Run ls -l and you get an exact count of bytes, which is what the filesystem records and what every API that reports a size returns. Run ls -lh on the same file and you get something like 24K. Nothing about the file changed between the two commands — the second divided by 1,024, rounded, and appended a letter that does not say which scale it used.

That is the reason to convert bytes to KiB by hand at all. The exact number is the one that has to match a header, a hash boundary or a quota; the rounded one is the number a colleague quotes back at you from a terminal. Being able to move between them without guessing which base the tool used is the whole skill here.

GNU coreutils uses upper-case K, M and G for powers of 1,024 and lower-case k for 1,000, which is a convention almost nobody knows and no tool announces. du -h reports binary. du --si reports decimal on the same directory and will differ by 2.4 per cent at the kilo step. df with no options prints 1 KiB blocks; df -h is binary; df -H is decimal.

The practical consequence is that "how big is this directory" has two correct answers from one command, and which one you get depends on a flag somebody typed a week ago in a script. If a number is going into a ticket or a capacity plan, record the flag with it, or convert to bytes first and let the reader pick their own scale.

Memory is addressed by lines that are either high or low, so the quantities a machine reaches for naturally are powers of two. Ten address lines reach 1,024 locations, which is close enough to a thousand that the kilo prefix was borrowed, and the borrowing was never undone. That is the historical accident the whole binary-versus-decimal argument descends from.

It is not only historical. Filesystems allocate in blocks that are powers of two, memory pages are 4,096 bytes on ordinary hardware, and disks moved from 512-byte sectors to 4,096-byte ones. Converting bytes to kibibytes is therefore the conversion that lands on real boundaries; converting bytes to decimal kilobytes gives a tidier number that nothing underneath is built to.

Every figure on this page counts bytes. Content-Length, file sizes, buffer lengths and disk usage are all byte counts, and a byte has been eight bits since the convention settled — early machines used six, seven or nine, and the eight-bit byte won partly because it holds one character and halves neatly.

Bit rates are the exception that bites. Link speeds, bandwidth caps and encoder settings are quoted in bits per second, so a 100 Mbit/s connection moves at most 12.5 MB per second, and dividing the two figures without noticing gives an answer wrong by a factor of eight. The letter case is the only signal: Mb is megabits, MB is megabytes.

A 900-byte file is 900 bytes long and takes 4,096 bytes of the volume, because storage is handed out in whole blocks. ls -l reports the first number and du reports the second, which is why a directory of small files can consume several times what its contents add up to. du --apparent-size switches du to the byte count and makes the two agree again.

This matters most at the small end, which is exactly where a bytes-to-KiB conversion lives. Ten thousand configuration files of 200 bytes each are 2 MB of content and roughly 40 MiB of disk. If the number you are converting came from a quota tool, it is probably allocated size; if it came from a length header, it is content.

Coreutils rounds its human-readable sizes up rather than to nearest, so a 1,025-byte file prints as 1.1K even though 1.0 would be nearer. The rule is that the display should never claim less than is there. Other tools round to nearest, and file managers frequently truncate, which is how three programs produce three sizes for one file and all of them look defensible.

You can use this deliberately. Create a file of exactly 1,025 bytes, list it, and read the answer: 1.1K means coreutils-style rounding on a 1,024 base, 1.0K means round-to-nearest, 1.0k or 1.1k means the decimal scale. That takes ten seconds and settles an argument that otherwise runs for an afternoon.

Some numbers cannot survive a conversion. A Content-Length must be the exact byte count or the response is malformed. A Range header addresses byte offsets. A multipart upload has a minimum part size expressed in bytes. A memory allocation is an integer count of bytes, and rounding it to a friendly unit is how an off-by-a-block bug gets written.

So convert for the human and keep the integer for the machine. The useful discipline is to store bytes everywhere in code and logs, and to convert only at the point of display, labelling the result KiB rather than KB so the next person does not have to work out which thousand you meant.

A sparse file is one whose unwritten regions are recorded as holes rather than stored as zeros, and it breaks the relationship between a byte count and a quantity of disk in the opposite direction from block rounding. A virtual machine image created at 40 GB may occupy a few hundred kibibytes until something writes to it. ls -l reports the full logical length, because that is what the file claims to be; du reports the tiny allocated figure, because that is what exists.

This is worth knowing before converting a byte count, because the two tools are answering different questions and only one of them is the question you have. If the number is going into a capacity plan, the allocated figure is the honest one and it will grow. If the number is going into a transfer estimate, the logical figure is what a naive copy will actually write, and the destination will need all of it unless the copying tool understands holes.