Mebibyte to Nibble

MB (megabyte) = 1,000,000 bytes (SI decimal). MiB (mebibyte) = 1,048,576 bytes (IEC binary). MiB is 4.86% larger. This gap is why a file manager on Linux showing "512 MiB" of free RAM and a marketing sheet showing "512 MB" of RAM are technically different: the marketing sheet refers to fewer bytes.

The original CD-ROM standard defined capacity as 74 minutes of audio or 650,000,000 bytes. Technically this is 650 MB in SI terms, or approximately 620 MiB (since 650,000,000 ÷ 1,048,576 ≈ 620). However, the CD industry loosely used "MB" to mean 650 × 10⁶ bytes. Some media used 700 MB (≈ 668 MiB). This inconsistency is a classic example of the pre-IEC ambiguity.

Docker reports image sizes in decimal MB (e.g., "docker images" shows 150 MB), but the underlying layer storage on disk uses binary-aligned block sizes. A "150 MB" Docker image actually occupies roughly 143 MiB on disk before compression. Compressed layers further complicate things: a 150 MB uncompressed image might only transfer 50 MB over the network. Container registries like Docker Hub display compressed sizes, while "docker images" shows uncompressed — leading to frequent confusion in CI/CD pipeline size budgets.

One mebibyte (1,048,576 bytes) holds about: one minute of MP3 audio at 128 kbps (≈ 960 kB, so slightly under 1 MiB), a medium-resolution JPEG photo (0.5–2 MiB), about 200 pages of plain text, or the complete text of a short novel. A typical Linux kernel image at boot is 8–12 MiB compressed.

RAM chips are physically organized as binary address grids — each address line doubles the capacity, so sizes must be exact powers of 2 (4 GiB = 2³² bytes, 8 GiB = 2³³ bytes). USB flash drives use NAND flash that is also binary internally, but manufacturers reserve variable amounts for wear levelling, bad block management, and controller firmware. A "64 GB" USB drive might have 64 GiB of raw NAND but only expose 59.6 GiB (64 × 10⁹ ÷ 2³⁰) to the user — the label uses decimal marketing, unlike RAM which honestly reflects binary sizing.

A nibble is 4 bits, or half a byte. It encodes one hexadecimal digit (values 0–15, represented as 0–9 and A–F). Nibbles are important in BCD (binary-coded decimal) encoding, where decimal digits are packed two per byte (each digit occupying one nibble). Packed BCD is used in financial systems and legacy databases to represent decimal numbers without floating-point rounding errors.

Hexadecimal (base 16) maps perfectly to nibbles because 4 bits can represent exactly 16 values (2⁴ = 16). One byte = two nibbles = two hex digits. A byte value of 0xFF (255 in decimal) is two nibbles: F (1111) and F (1111). This mapping makes hexadecimal the natural notation for expressing binary data — programrs use hex because one hex digit always represents a fixed number of bits.

Binary-Coded Decimal (BCD) encodes each decimal digit (0–9) as a 4-bit binary value (nibble). Two decimal digits fit in one byte using "packed BCD". For example, the decimal number 47 is stored as 0100 0111 in packed BCD — each nibble holds one digit. BCD avoids the rounding errors of binary floating-point, which is why it is used in financial software, calculators, and legacy banking systems.

A nibble = 4 bits (1 hex digit). A byte = 8 bits (2 hex digits, 2 nibbles). A word = typically 16, 32, or 64 bits depending on the processor architecture (see the "word" unit for details). These are the fundamental granularities of digital data: nibble for hex/BCD, byte for text and addressing, word for native processor arithmetic.

Nibbles are rarely referenced directly in modern high-level programming but remain fundamental at the hardware level. Embedded systems, FPGA design, network packet parsing, and hardware description languages (VHDL, Verilog) regularly manipulate nibbles. The nibble is also the key concept behind hexdump utilities — the canonical way to inspect raw binary files and network packets.