Convert kB to GiB

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 gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

The factor is 0.000001, and almost nobody carries that around. Rounded to 0.000001 it is off by 0.14 % — 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 GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1073741.824 kB and 1000000 kB — 7.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 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 1000000 kB where the box said 1073741.824. 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 per-item size almost always arrives in decimal kilobytes. A log line is 1.2 kB, a JSON record is 4 kB, an email without attachments is 15 kB, a map tile is 30 kB. These are measurements of content, produced by counting bytes and dividing by a thousand, and the people who produce them are thinking about payloads rather than storage.

The budget those items have to fit is reported by something else entirely. A volume, a memory cache, a container limit and a retention policy are all expressed in gibibytes, because the software reporting them computes in powers of 1,024. So this conversion sits at the join between a measurement of content and a measurement of capacity, and it has to cross both a prefix gap of a million and a unit-system gap of 7.37 per cent.

One gibibyte holds 1,073,741.824 kB. The rough version — a million kilobytes to the gibibyte — is out by 6.9 per cent, and it over-states how many gibibytes a given pile of kilobytes needs. That is the safe direction to be wrong in and still the wrong number to write down, since using 1.074 million instead costs nothing and removes the error entirely.

For mental work the cleaner form is per item rather than per gibibyte. A 1 kB item goes about 1,074,000 to the gibibyte; a 4 kB item about 268,000; a 30 kB item about 35,800. Turning the ratio into a count of things rather than a count of kilobytes makes it far easier to sanity-check, because a count of records is a number the reader already has a feel for.

Most estimates of this shape start as a rate rather than a total, and the rate is where the arithmetic becomes surprising. One kilobyte per second is 86,400 kB a day, which is 0.0805 GiB, or 29.4 GiB a year. Ten kB/s is 294 GiB a year. A hundred kB/s — which is a single moderately chatty service — is 2.87 TiB a year.

The step people skip is that a rate quoted per instance multiplies by instances and then by retention. Forty services at 10 kB/s with ninety days of retention is 40 × 0.805 GiB per day × 90, which is 2,898 GiB, or 2.83 TiB, held at all times. None of the individual figures looked like a storage problem and the product is a shelf.

It is worth being blunt about this, because a page about a unit conversion has an incentive not to be. The 7.37 per cent between the decimal and binary scales is real and should be applied. It is also, on an estimate built from per-item sizes, usually the fourth or fifth largest source of error.

Ahead of it: whether the measured item size included framing and headers, whether the store keeps an index and how large it is, whether the data is replicated two or three times, whether it is compressed and at what ratio, and whether the retention period is the one in the policy or the one actually configured. Each of those is a multiplier rather than a percentage, and any one of them can double the answer.

A filesystem hands out space in blocks, normally 4 KiB. A 2 kB record written as its own file occupies 4,096 bytes, so a million of them are 2 GB of content and 3.81 GiB of disk. At 500 bytes each the ratio is worse: 0.5 GB of content becomes the same 4,096,000,000 bytes on disk, roughly eight times the measured size.

The same records packed into log segments, database pages or object-store objects cost their own size plus a few bytes of framing, and the block rounding happens once per segment rather than once per record. This is why the storage layout is worth establishing before the unit conversion is: converting carefully and then multiplying by the wrong storage model gives an answer that is precise about the wrong quantity.

Text compresses well and log lines compress very well — ratios of five or ten to one are ordinary for structured text with repeated field names. Applying that at the right point matters for whether the estimate can be checked later. Compress the per-item figure, note the ratio you assumed, then multiply by the count and convert.

Doing it the other way round — converting to gibibytes and then dividing by a compression ratio — gives the same number and loses the audit trail. When the store turns out to compress at three to one rather than eight, the person revising the estimate needs to see which figure was measured and which was assumed, and a single blended number does not tell them.

The useful format is a chain of lines, each with its own unit: measured size per item in kB, item rate per second, instances, retention in days, compression ratio, replication factor, then the total in bytes and finally in GiB. Seven lines, and every one of them is a number somebody can challenge on its own.

The alternative — a single figure with the working done in somebody’s head — is not wrong more often, but it is unfixable when it is. Storage estimates are revisited every time consumption diverges from them, and the ones that survive that process are the ones where the divergence can be attributed to a line rather than to the estimate as a whole.

It is worth being explicit about why the two sides of this conversion use different systems, because it is not arbitrary. The item size was produced by counting content — a payload, a row, a message body — and content has no natural block structure, so it is counted in decimal like every other measurement of a quantity of stuff. The budget was produced by something that allocates: a kernel, a container runtime, a filesystem, a memory allocator. Those work in powers of two because the hardware underneath them does.

So the conversion is not a translation between two arbitrary conventions but a move from measuring content to measuring the container it goes in, and the container has a shape. That is also why the block-rounding term dominates the unit term on small items: the shape of the container matters more than the name of its unit. Estimating in bytes and applying the storage model explicitly keeps both effects visible instead of blending them into a single fudge factor.