Number Base Conversion: Binary, Octal, Hex in Programming

Working software engineers who have only ever written high-level application code can sometimes coast without deeply understanding number bases. But the moment you touch networking (IP addresses, subnet masks), cryptography (hashes, keys), hardware interfaces (register maps, protocol bytes), file formats (magic bytes, binary parsing), or performance-critical code (bitwise optimizations), the ability to fluently read and write binary, octal, and hexadecimal becomes essential — not optional.

The reason these bases exist at all is rooted in hardware architecture. Modern processors operate on **bits** — binary digits that are either 0 or 1, representing the on/off state of transistors. Every integer in memory is a binary pattern. Hexadecimal emerged as a shorthand because one hex digit represents exactly **four binary digits (bits)**, making it trivially easy to translate between the two. A 64-bit integer is 64 binary digits but only 16 hex digits — far more manageable for humans to read and write.

Octal (base 8) was more prominent in early computing when machines had word sizes that were multiples of 3 bits (6-bit, 12-bit, 36-bit architectures). It survives today primarily in Unix file permission notation: `chmod 755` means owner has rwx (7 = 111 binary), group has r-x (5 = 101 binary), others have r-x. Understanding this requires octal literacy.

Beyond historical reasons, fluency in number bases makes you a faster debugger. Reading a hex dump, understanding why `0xFF & value` masks the lower 8 bits, or recognizing that an octet IP address like `192.168.1.0/24` has exactly 8 host bits — these insights come naturally once you internalize the relationships between bases. This guide builds that fluency from first principles through practical programming examples.

Every number system is a **positional notation** where each digit's value depends on its position (its power of the base). In base 10 (decimal), the number `347` means `3×10² + 4×10¹ + 7×10⁰ = 300 + 40 + 7`.

The same principle applies to any base: ``` Binary (base 2): 1011₂ = 1×2³ + 0×2² + 1×2¹ + 1×2⁰ = 8 + 0 + 2 + 1 = 11₁₀

Octal (base 8): 1357₈ = 1×8³ + 3×8² + 5×8¹ + 7×8⁰ = 512 + 192 + 40 + 7 = 751₁₀

Hexadecimal (base 16): 2AF₁₆ = 2×16² + 10×16¹ + 15×16⁰ = 512 + 160 + 15 = 687₁₀ ```

Hex uses letters A–F for digits 10–15, since a single character must represent values 0–15.

**Decimal to another base — the repeated division algorithm:** ``` Convert 687₁₀ to hex: 687 ÷ 16 = 42 remainder 15 (F) 42 ÷ 16 = 2 remainder 10 (A) 2 ÷ 16 = 0 remainder 2 Read remainders bottom to top: 2AF₁₆ ✓ ```

**Shortcut: Hex ↔ Binary** (memorize this table): ``` 0=0000 1=0001 2=0010 3=0011 4=0100 5=0101 6=0110 7=0111 8=1000 9=1001 A=1010 B=1011 C=1100 D=1101 E=1110 F=1111 ```

With this table, converting `0xDEAD` to binary requires no arithmetic — just substitute each hex digit: `D→1101 E→1110 A→1010 D→1101` Result: `1101 1110 1010 1101₂`

This bidirectional substitution is why hex is the professional shorthand for binary data. It reduces a 16-bit pattern from 16 binary digits to 4 hex digits while preserving the exact bit layout, making it easy to spot patterns, masks, and flags at a glance.

Every major programming language provides built-in support for binary, octal, and hexadecimal literals and conversion functions. Knowing the syntax for your language prevents the need to write manual conversion code.

**Python:** ```python # Literals b = 0b10110011 # binary o = 0o755 # octal h = 0xDEADBEEF # hexadecimal

# Conversion TO string bin(187) # '0b10111011' oct(511) # '0o777' hex(3735928559) # '0xdeadbeef'

# Conversion FROM string int('0b10110011', 2) # 179 int('0755', 8) # 493 int('0xDEAD', 16) # 57005 # Or with base parameter: int('FF', 16) # 255 int('10110011', 2) # 179 ```

**JavaScript:** ```javascript // Literals const b = 0b10110011; // 179 const o = 0o755; // 493 const h = 0xDEAD; // 57005

// Number to string in base (255).toString(2) // '11111111' (255).toString(8) // '377' (255).toString(16) // 'ff'

// String to number parseInt('ff', 16) // 255 parseInt('10110011', 2) // 179 Number('0xFF') // 255 (hex prefix) ```

**C / C++:** ```c // Literals int b = 0b10110011; // binary (C23/GCC extension) int o = 0755; // octal (leading zero!) int h = 0xDEAD; // hex

// Note: a leading 0 on an integer literal means OCTAL in C/C++ // 08 and 09 are NOT valid octal digits — compile error

// Formatting printf("%d %o %x\n", 255, 255, 255); // 255 377 ff ```

**Rust:** ```rust let b: u32 = 0b10110011; let o: u32 = 0o755; let h: u32 = 0xDEAD;

println!("{:b} {:o} {:x}", 255u32, 255u32, 255u32); // Output: 11111111 377 ff ```

A critical **gotcha** in C/C++: any integer literal with a leading zero is interpreted as **octal**, not decimal. `0755` is 493 in decimal, not 755. This has caused real bugs in security-sensitive code where octal file permission constants were accidentally interpreted as decimal.

Integer representation in binary is not as simple as "write the number in binary." **Signed integers** (which can be negative) use a scheme called **two's complement**, and misunderstanding it leads to subtle bugs involving integer overflow, sign extension, and bitwise operations on negative numbers.

In two's complement, the most significant bit (MSB) is the **sign bit**: 0 = positive, 1 = negative. The remaining bits encode the magnitude in a specific way:

``` 8-bit signed integers: 127 = 0111 1111 1 = 0000 0001 0 = 0000 0000 -1 = 1111 1111 ← NOT 1000 0001 -2 = 1111 1110 -127 = 1000 0001 -128 = 1000 0000 ← most negative 8-bit value (no positive counterpart) ```

**To negate a two's complement number:** flip all bits, then add 1. ``` To negate 5 (0000 0101): Flip bits: 1111 1010 Add 1: 1111 1011 = -5 ✓ ```

This scheme is used by every modern CPU for signed integers. Understanding it is essential for:

**Overflow detection:** In C, `int max = 2147483647; max + 1;` causes undefined behavior (signed overflow). The bit pattern wraps from `0x7FFFFFFF` to `0x80000000`, which in two's complement is the most negative 32-bit integer (`-2147483648`).

**Bitwise right shift on signed values:** In most languages, right-shifting a negative number performs **arithmetic right shift** (fills with 1s to preserve sign) rather than logical right shift (fills with 0s). In JavaScript, `>>` is arithmetic, `>>>` is logical: ```javascript (-8) >> 1 // -4 (arithmetic: fills with 1s) (-8) >>> 1 // 2147483644 (logical: fills with 0s, treats as unsigned) ```

**Sign extension** occurs when a smaller signed value is widened to a larger type: the sign bit is replicated into the new high-order bits. A `int8_t` value of `-1` (`0xFF`) sign-extends to `int32_t` `0xFFFFFFFF` (`-1`), not `0x000000FF` (`255`).

Bitwise operations are the most direct application of binary fluency in day-to-day programming. They appear in networking, cryptography, game development, hardware drivers, compression algorithms, and performance optimization.

**The six core bitwise operators:** ``` AND (&) : both bits must be 1 OR (|) : at least one bit must be 1 XOR (^) : exactly one bit must be 1 NOT (~) : flip all bits SHL (<<) : shift left N positions (multiply by 2^N) SHR (>>) : shift right N positions (divide by 2^N, arithmetic) ```

**Common idioms — every professional programmer should recognize these:**

```c // Test if bit N is set bool bit_n_set = (value >> n) & 1;

// Set bit N value |= (1 << n);

// Clear bit N value &= ~(1 << n);

// Toggle bit N value ^= (1 << n);

// Mask lower 8 bits (extract a byte) uint8_t byte = value & 0xFF;

// Check if value is a power of 2 bool is_pow2 = (value > 0) && ((value & (value - 1)) == 0);

// Round up to next power of 2 (for buffer allocations) uint32_t next_pow2(uint32_t v) { v--; v |= v >> 1; v |= v >> 2; v |= v >> 4; v |= v >> 8; v |= v >> 16; return v + 1; }

// Swap without temp variable (XOR swap) a ^= b; b ^= a; a ^= b; ```

**Hex flags** are the canonical way to express bitmask constants: ```c #define PERM_READ 0x01 // 0000 0001 #define PERM_WRITE 0x02 // 0000 0010 #define PERM_EXECUTE 0x04 // 0000 0100 #define PERM_ADMIN 0x80 // 1000 0000

uint8_t user_perms = PERM_READ | PERM_WRITE; // 0x03

if (user_perms & PERM_EXECUTE) { // user can execute } ```

This pattern appears everywhere: Linux `open()` flags, HTTP option bitfields, game entity state flags, CSS computed style bitmasks, and network protocol headers.

The practical value of number base fluency is clearest in domains that work directly with binary data at scale.

**Networking — IP Addresses and Subnet Masks:** IPv4 addresses are 32-bit integers written in dotted decimal notation. `192.168.1.0/24` means a 24-bit network prefix. The subnet mask `255.255.255.0` in binary is `1111 1111 . 1111 1111 . 1111 1111 . 0000 0000`. The `/24` means the first 24 bits identify the network, the last 8 bits identify the host — allowing 254 usable host addresses.

Checking if two IPs are in the same subnet: ```python ip = 0xC0A80105 # 192.168.1.5 mask = 0xFFFFFF00 # 255.255.255.0 net = 0xC0A80100 # 192.168.1.0

print((ip & mask) == (net & mask)) # True ```

IPv6 addresses are 128-bit values written in colon-separated hex groups: `2001:0db8:85a3:0000:0000:8a2e:0370:7334`. Hex fluency is essential for reading and reasoning about IPv6 subnets.

**Cryptography — Hash Values and Keys:** Cryptographic hashes (SHA-256, BLAKE3, SHA-512) are binary outputs conventionally displayed as hex strings. A SHA-256 hash is 256 bits = 32 bytes = 64 hex characters. When comparing hash values in code, always compare the raw bytes, not the hex string — string comparison is slower and case-sensitive. When displaying, use lowercase hex for consistency (`hashlib.sha256(data).hexdigest()` in Python produces lowercase).

Random nonces, HMAC keys, and AES keys are generated as random byte arrays and stored/transmitted as hex or base64. Understanding when to use hex (compact binary representation, human-readable) vs base64 (more compact for transport, URL-safe variant available) is part of cryptographic engineering literacy.

**File Formats — Magic Bytes:** Almost every binary file format begins with a **magic number** — a fixed byte sequence that identifies the format. These are always expressed in hex: ``` PNG: 89 50 4E 47 0D 0A 1A 0A (\x89PNG\r\n\x1a\n) PDF: 25 50 44 46 (%PDF) ZIP: 50 4B 03 04 (PK\x03\x04) ELF: 7F 45 4C 46 (\x7fELF) JPEG: FF D8 FF (starts) MP4: 66 74 79 70 (ftyp, at offset 4) ```

A file validation function reads the first N bytes and compares them to the expected magic bytes in hex — a task that requires comfortable hex reading.

Professional programmers develop mental shortcuts for base conversion that work without paper or a calculator. Building these reflexes makes binary and hex feel as natural as decimal.

**Powers of 2 — memorize through 2^16:** ``` 2^0 = 1 2^4 = 16 2^8 = 256 2^12 = 4,096 2^1 = 2 2^5 = 32 2^9 = 512 2^13 = 8,192 2^2 = 4 2^6 = 64 2^10 = 1,024 2^14 = 16,384 2^3 = 8 2^7 = 128 2^11 = 2,048 2^15 = 32,768 2^16 = 65,536 ```

Knowing these cold means: - `0xFFFF` = 65,535 (2^16 - 1, max 16-bit unsigned value) — instant recognition - `0x7FFFFFFF` = 2,147,483,647 (2^31 - 1, max 32-bit signed int) — instant recognition - `1 << 20` = 1,048,576 ≈ 1 million — useful for memory calculations

**Hex reading shortcut — think in nibbles:** A nibble (4 bits) maps directly to one hex digit. Train yourself to see hex in 2-digit (byte) chunks: - `0xAB` = upper nibble A (1010) + lower nibble B (1011) = `10101011` - `0x80` = the sign bit of a signed byte is set; value is -128 in int8_t - `0x0F` = lower 4 bits all set, upper 4 all clear — common mask

**Octal in practice — Unix permissions:** Think of each octal digit as one permission group: - `755` → owner: `7`=rwx · group: `5`=r-x · others: `5`=r-x - `644` → owner: `6`=rw- · group: `4`=r-- · others: `4`=r-- - `600` → owner: `6`=rw- · group: `0`=--- · others: `0`=--- (private file)

With practice, reading `chmod 0o644` or writing the correct permission for a web server config file becomes automatic — no mental arithmetic needed, just pattern recognition from the octal digit directly to the permission set.