Convert kB to GB

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

Going from kilobytes to gigabytes moves the decimal point 6 places to the left and changes nothing else. There is no factor to remember and no rounding to decide: the digits stay in the same order and only their position changes.

1,234 kB is 0.001234 GB — same digits, moved along. That is worth knowing because it is the one kind of conversion you can check at a glance: if the digits of the answer are not the digits you started with, something other than the conversion has happened to them.

Decimal makes this ratio a clean power of ten: a kilobyte is 10³ bytes, a gigabyte is 10⁹, and there are exactly a million kilobytes in a gigabyte. That is what SI prefixes mean, and it is the convention used by storage manufacturers, by every network standard and by the services that quote you a capacity. The conversion is six places of the decimal point with no factor to remember at all.

The mistake this pair produces is a factor of a thousand, not a factor of 1.05. Somebody who has the megabyte relationship in their head — a thousand of them to the gigabyte — reaches for the same thousand here and lands three orders of magnitude out. A useful guard is to say the answer out loud with its scale attached: 500,000 kB is half a gigabyte, and if a total in the hundreds of thousands of kilobytes comes out in the hundreds of gigabytes, a step has been skipped.

The shape of the calculation is always the same: an average item size in kilobytes, multiplied by a count, divided by a million. Fifty million log lines a day at 2 kB each is 100,000,000 kB, which is 100 GB a day and 36.5 TB a year. Two hundred thousand thumbnails at 40 kB is 8,000,000 kB, or 8 GB. Ten million database rows at 1.5 kB is 15 GB before any index is counted.

The weak number in that chain is almost never the division. It is the average, because file and record sizes are long-tailed: a handful of very large items pulls the mean well above the median, and an average measured on a hundred samples can be out by a factor of two. Measure the average on a real sample of the real data, state the count it came from, and quote the result to one or two significant figures rather than to the nearest gigabyte.

A filesystem does not hand out bytes; it hands out blocks, and the common default on both ext4 and NTFS is 4,096 bytes. A 1 kB file occupies a full block, a 5 kB file occupies two, and a 4.1 kB file occupies two as well. So a million files averaging 1 kB contain a gigabyte of data and occupy about 4 GiB of disk — four times the estimate, produced entirely by rounding that has nothing to do with the units.

The effect fades as items get larger and disappears above a few tens of kilobytes, where the wasted tail of the last block is a small fraction of the file. It never applies to records inside one large file: a million 2 kB rows in a single database file or one log file are packed end to end, and the block rounding happens once for the whole file rather than a million times. Whether the small things are files or rows is therefore the first question to ask about any estimate at this scale.

Almost everything that comes in kilobyte-sized pieces is text, and text compresses hard. Log lines, JSON documents, CSV exports and SQL dumps typically fall to between a fifth and a tenth of their size with a general-purpose algorithm, because they repeat field names, timestamps and structure on every line. An uncompressed estimate of 100 GB a day is frequently a 10 to 20 GB a day storage bill once the data is at rest.

The exception is content that has already been compressed. JPEG thumbnails, MP3 previews and video segments carry no useful redundancy left to remove, and running them through an archiver gains a per cent or two at best. So an estimate should be built in two parts: text at its compressed size, media at its stored size, and the two totalled rather than a single ratio applied to everything.

This page divides by 1,000,000. The binary equivalent divides by 1,048,576, because a gibibyte is 1,024² kibibytes rather than 1,000² kilobytes, and the two divisors are 4.9 per cent apart. That is larger than the 2.4 per cent gap between a kilobyte and a kibibyte, and smaller than the 7.4 per cent between a gigabyte and a gibibyte — the difference grows with each 1,024 step taken, and this pair takes two of them.

On an estimate carrying a two-fold uncertainty in the average item size, 4.9 per cent is not the thing to worry about. It matters when the numbers are exact rather than estimated: reconciling a billing figure against a filesystem report, or checking that a migration moved everything it was supposed to. There the rule is to convert once, from an exact byte count, and to state which divisor was used.

The Unix tools most people reach for at this scale are the ones least likely to mean decimal kilobytes. du and df report in 1,024-byte blocks by default and label them K or KB, a convention that predates the kibibyte by decades. A directory reported as 4,096 K is 4,194,304 bytes, and a filesystem reported as 976,562,500 K is a terabyte exactly.

Both accept a flag that switches to powers of ten, and the difference is worth knowing before a number leaves your terminal for a spreadsheet. Across a terabyte the two readings differ by 24 GB, which is enough to make a capacity plan look comfortable when it is not. Record which convention a figure came from at the moment you copy it, because nothing about the number itself will tell you afterwards.

An estimate assembled from an average, a count and a compression guess deserves to be quoted as a range rather than a figure. "Between 8 and 20 GB a day, from a sample of ten thousand lines averaging 2.1 kB, compressing at about 6:1" is a sentence somebody else can check and argue with. "13.4 GB a day" is not, and it will be treated as a measurement.

It is also worth writing down what the estimate excludes, because the omissions at this scale are usually larger than the arithmetic. Indexes on a database frequently add half again to the size of the rows; a log pipeline holds the same data in a buffer, a hot store and an archive at once; and retention is a multiplier, so a daily figure means nothing until the number of days it is kept for is attached to it.