Convert KiB to GB

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 gigabyte is a billion bytes in the decimal sense used by drive manufacturers, phone plans and video sizes.

The factor is 0.000001, and almost nobody carries that around. Rounded to 0.000001 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 0 GB and 0 GB — 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 0 GB where the box said 0. 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 measurement side of a web system counts in binary units because the tools that produce it do. An average object size comes from a file listing, a build report or a storage bucket summary, and all of those divide by 1,024. The commercial side counts in decimal gigabytes, because that is how transfer has been sold since long before anybody had to distinguish the two.

One object is unaffected by the difference and a month of traffic is not. A million requests averaging 250 KiB is 256,000,000,000 bytes, which is 256 GB. Reaching for a thousand instead of 1,024 gives 250 GB, an understatement of six gigabytes that scales exactly with traffic: double the requests and the shortfall doubles too.

The reliable order is to keep everything in bytes for as long as possible. Take the per-object size in kibibytes, multiply by 1,024 to get bytes, multiply by the count, and only then divide by a billion. Every step before the last is integer arithmetic and exact, and the single division at the end is the only place a rounding decision has to be made.

Doing it the other way round — converting each object to gigabytes and adding the results — introduces a rounding error per item, and the number of items is precisely the quantity that makes the total large. A spreadsheet built that way can be several per cent adrift for reasons that are invisible in any individual row, which makes the discrepancy extremely difficult to find later.

Access logs record bytes, not kibibytes, which is the one piece of good news in this calculation. The bytes-sent field is a raw count per request, so summing the column and dividing by a billion gives decimal gigabytes with no unit question at all. Where the number arrives already summarised in KiB — a dashboard, a report, a colleague’s message — the conversion has to be applied and it is worth asking what the summary rounded.

The other thing a log will tell you that an average cannot is the shape of the distribution. A mean object size of 250 KiB might be ten thousand small responses and a handful of very large ones, and a forecast built on the mean will be right in total and wrong about every operational consequence — cache behaviour, connection counts, the effect of a size limit. The total is the easy part.

The payload is not the transfer. Response headers add several hundred bytes to every request and are sent whether the body is cached or not, protocol negotiation costs bytes on each new connection, redirects transfer twice, and failed requests that were retried are counted for each attempt. On a fleet of small objects that overhead can be a serious fraction of the whole, and none of it appears in the object size a storage listing reports.

This is worth stating alongside the units correction because the two pull in the same direction and are easy to confuse. If a provider reports more usage than the calculation predicted, the units gap explains 2.4 per cent of it and no more. Anything beyond that is traffic the model did not account for, and looking for it in the arithmetic rather than in the request pattern wastes the afternoon.

Take the average object size in kibibytes, multiply by 1,024 for bytes, multiply by the expected request count, and divide by a billion. Ten million requests at 100 KiB is 1,024,000,000,000 bytes, which is 1,024 GB, or 1.024 TB. That last figure is a useful sanity landmark in itself: ten million hundred-kibibyte objects is almost exactly a decimal terabyte.

Then apply the uncertainty honestly. A forecast that is precise to four significant figures on the units and vague to a factor of two on the request count has not been made more accurate by the conversion. State the total as a range driven by the traffic estimate, and use the exact factor so that at least the arithmetic is not adding error of its own.

Reconciliation works best in bytes on both sides. Convert the provider’s billed gigabytes back to bytes by multiplying by a billion, sum your own logged byte counts, and compare the two integers. Any difference then has a cause worth naming rather than being lost in a comparison between two rounded figures with unstated units.

A discrepancy of about 2.4 per cent points at the kibibyte-versus-kilobyte gap somewhere in the chain, usually in a summary that was produced by a binary tool and read as decimal. A discrepancy of 7.4 per cent points at the same mistake made one prefix higher. Recognising the size of the gap is often faster than tracing where it happened.

Two different meters run on the same objects. Storage is charged by capacity held over time, usually as gigabyte-months prorated to the hour, so an object that exists all month costs its full size and one deleted on the fifteenth costs half. Transfer is charged per gigabyte moved, so the same object costs nothing until somebody requests it and then costs its size on every request that is not served from a cache.

Both meters count decimal gigabytes, which at least means one conversion covers both. What differs is what the kibibyte figure has to be multiplied by: object count for storage, request count for transfer. A library of a million 250 KiB objects is 256 GB of storage every month regardless of traffic, and anything from nothing to many terabytes of egress depending on how often it is read.

Mailbox quotas, per-user storage allowances and API response limits are frequently defined in binary units by the software that enforces them and communicated to users in decimal terms, or the reverse. A 15 GB allowance enforced as 15 GiB gives every user 1.11 GB more than the documentation promises, across the whole user base, and nobody complains — which is why it goes unnoticed for years.

The version that does generate complaints is the opposite. An allowance advertised as 15 GB and enforced as 15,000,000,000 bytes will look short to any user whose client reports usage in gibibytes, because their 14 GiB of mail is 15.03 GB and has already exceeded it. The fix is not more capacity; it is stating the unit in the same place the number is stated.