Convert KiB to MiB

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 mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

Going this way is a division, and by a whole number: 1,024 of these fit into one mebibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a mebibyte, 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 0.001 MiB and 0.001 MiB — 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.001 MiB where the box said 0.001. 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 command that produced your number matters more than the arithmetic that follows it. GNU du counts allocated disk blocks in units of 1,024 bytes, so du -sk build/ answers "how much of the filesystem is spoken for", not "how many bytes of content are in there". ls -l reports the second number, in bytes, and the two routinely disagree by a factor of several for the same directory.

That matters the moment the MiB figure goes into a decision. Sizing a tarball, a container image layer or an upload quota is a content question and wants apparent size; sizing a partition or checking why a volume filled up is an allocation question and wants what du printed. Converting the wrong one to MiB gives an answer that is arithmetically perfect and about the wrong quantity. stat settles it for a single file: the Size line is the length in bytes, the Blocks line is the allocation counted in 512-byte units regardless of what the filesystem uses, and halving the second gives kibibytes. Where the two disagree by more than one block, the file is sparse or the filesystem is compressing it.

The prefixes are contractions: kilobinary became kibi, megabinary became mebi, gigabinary gibi. The IEC adopted them in 1998 as an amendment to IEC 60027-2, the IEEE restated them in IEEE 1541 in 2002, and they now sit in ISO/IEC 80000-13. The intention was that "kilobyte" could go back to meaning a thousand bytes in every context, with the binary sense given a name of its own.

Adoption went one way and stopped. Linux and BSD tooling, most standards documents, several hypervisors and Kubernetes all use the IEC prefixes; storage marketing, Windows, macOS user-facing sizes and most programming-language documentation never did. That split is why a kibibyte figure on your screen almost certainly came out of a Unix tool, and why the same quantity elsewhere would have been labelled KB with no way to tell which one was meant.

du -h, ls -lh, df -h and free -h all default to powers of two and print a single-letter suffix — K, M, G — with no "i" anywhere in sight. The --si flag switches the same tools to powers of ten and prints a lower-case k instead. The case of that one letter is the entire signal, and it is invisible in a screenshot pasted into a ticket.

So a listing that reads 3.5M is 3.5 MiB, or 3,670,016 bytes, and handing that figure to something that assumes megabytes puts you 4.9 per cent low. Where the number is going to be quoted rather than acted on, du -B1 or ls -l gives raw bytes and removes the ambiguity entirely; it is harder to read and impossible to misinterpret. ls -l --block-size=K and du --block-size=K say the unit out loud in the output, which is worth the extra typing in anything that will be pasted into a ticket or a runbook rather than read once and discarded.

Filesystems hand out space in blocks. The default block size is 4 KiB on ext4, XFS and NTFS alike, which happens to match the memory page size on x86-64 and is not a coincidence. A file of 200 bytes occupies one block; so does a file of 4,096 bytes; a file of 4,097 bytes occupies two. The wasted remainder is called slack, and it is invisible until you convert a directory total to MiB and it comes out several times larger than you expected.

The arithmetic is worth doing once. Ten thousand files averaging 200 bytes hold about 2 MiB of content and occupy 40,960 KiB — 40 MiB — of disk. du --apparent-size -sk reports the content figure and plain du -sk the allocated one, and a node_modules tree or a Maildir will show the gap at its worst.

One kibibyte is 2¹⁰ bytes and one mebibyte is 2²⁰, so going between them is a ten-bit shift. Every KiB value converts to a MiB value that terminates in decimal — 1 KiB is 0.0009765625 MiB, written out in full with no rounding and no repeating tail — because 1,024 has no prime factor other than two, and decimal fractions terminate for exactly those denominators.

This is the one corner of unit conversion where a floating-point result can be trusted without qualification. Any KiB count below 2⁴³ divides by 1,024 into a double-precision float with every bit intact, since both the numerator and the divisor are powers of two and the exponent absorbs the shift. Converting kilograms to pounds cannot make that claim; this can.

du -sk gives a plain integer of kibibytes and du -sh gives a rounded, human-sized string. The rounded form is for reading and the integer is for arithmetic, and mixing them up is how a capacity spreadsheet ends up several per cent adrift with no single line obviously wrong. Rounded output carries three significant figures at most, so 1.1G has thrown away everything below about 50 MiB.

The practical habit is to collect in KiB and format at the end. du -sk | sort -n sorts correctly; du -sh | sort -h needs the -h flag on sort as well and will silently misorder without it, because plain lexical sorting puts 1.1G above 9.9M. Convert to MiB when a person is going to read the number, not before.

Several places on a Linux system are counted in KiB by definition, and a MiB figure has to be turned back before it can be used. ulimit -s is a stack limit in kibibytes, commonly 8192. Disk quotas are set and reported in 1 KiB blocks. The size= option on a tmpfs mount is the trap in the set: the kernel documentation says a bare number is bytes, so size=65536 gives you 64 KiB and not the 64 MiB somebody counting in kibibytes expected — append k, m or g and say what you mean. Nearly every field in /proc/meminfo is kibibytes under a label reading kB, the exceptions being the HugePages_ lines, which are counts of pages with no unit at all.

Where the destination is one of those, the useful direction is the other one, and the conversion here is for reading rather than for configuring. Work out the MiB figure to check that 8192 is eight mebibytes and not eight megabytes, then put the kibibyte number back in the field unchanged.