Q: Why do memory addresses use hex?

Memory addresses in computer systems are binary values — pointers are N-bit unsigned integers (32-bit on 32-bit systems, 64-bit on 64-bit systems) that identify a location in the process's address space. Hex is used to display them because: (1) The power-of-2 relationship: every 4 bits = 1 hex digit. A 64-bit pointer = 16 hex digits. Reading 0x00007FFF5FBFF678 is manageable; reading the same value in binary (64 ones and zeros) is not. (2) Alignment visibility: memory allocators and hardware requirements often align data to power-of-2 boundaries (4-byte aligned, 8-byte aligned, 16-byte aligned, 4096-byte page-aligned). Alignment is immediately visible in hex: 0x7FFF5FBFF000 ends in three zeros, indicating it's page-aligned (4096 = 0x1000). In decimal, 140734799806464 offers no such visual cue. (3) Byte boundary clarity: hex naturally groups into bytes (every 2 hex digits = 1 byte). A 4-byte integer in memory occupies 8 hex digits; the byte boundaries are obvious. (4) Protocol and format specifications: network protocols (Ethernet, IP, TCP), file format specs (ELF, PE, DWARF), and CPU architecture manuals (Intel SDM, ARM Architecture Reference) all specify bit fields and byte offsets in hex. Being fluent in hex is a prerequisite for reading these documents. Per Randall Hyde, The Art of Assembly Language §1.4: 'One of the first things assembly language programmers learn is to think in hexadecimal. Not because it's more natural than decimal, but because the relationship between hex and binary is so direct that thinking in hex is effectively thinking in binary with much less visual noise.'

Q: What's the maximum value of a 32-bit unsigned integer and why does it matter?

The maximum value of a 32-bit unsigned integer is 2³² − 1 = 4,294,967,295. In hex: 0xFFFFFFFF. In binary: 32 ones. This value appears in several important contexts that software developers encounter regularly: IPv4 address space: the maximum IPv4 address (255.255.255.255) is 0xFFFFFFFF = 4,294,967,295 — representing the broadcast address. The total IPv4 address space is 2³² = 4,294,967,296 unique addresses. Array and string size limits in C: on 32-bit systems, size_t is a 32-bit unsigned integer, so the maximum size of an array or string is 4,294,967,295 bytes (approximately 4 GiB). Signed 32-bit maximum (for comparison): 2³¹ − 1 = 2,147,483,647 = 0x7FFFFFFF — this is the maximum positive value for a signed 32-bit integer, and it is the Unix timestamp for 2038-01-19T03:14:07Z (the Y2K38 limit). Loop counter overflow: a common bug in C is using a signed int for a loop counter that approaches INT_MAX. If the counter is compared to an unsigned value of similar magnitude, the signed-to-unsigned conversion can make the loop run forever. Memory map ranges: 32-bit systems have a virtual address space from 0x00000000 to 0xFFFFFFFF (4 GiB total). On Windows 32-bit, the upper 2 GiB (0x80000000–0xFFFFFFFF) is reserved for the kernel; user-mode processes have 2 GiB of address space by default. POSIX mmap flags: MAP_FAILED = (void*)−1 = all bits set = 0xFFFFFFFF on 32-bit systems.

Q: Can I enter a number with a 0x, 0b, or 0o prefix?

Yes. The converter accepts an optional source-base prefix and strips it when it matches the base you selected: 0x for hexadecimal, 0b for binary, and 0o for octal — in either case (0xDEAD and 0xdead both work). Digit-group underscores and surrounding whitespace are also ignored, so you can paste 1111_1111 or 0xFF_FF directly the way you would write a numeric literal in Rust, Python, or modern C++. If a prefix does not match the selected base — say you paste 0b1010 while the base selector is on hexadecimal — the leading 0 and b are treated as ordinary digits, and because b is a valid hex digit (11) you'll get a value, so double-check the base selector matches your prefix. This calculator never silently coerces: an illegal digit for the chosen base raises a clear error instead of dropping the bad character.

Q: How large a number can this converter handle, and why is there a limit?

Inputs are capped at JavaScript's largest safe integer, Number.MAX_SAFE_INTEGER = 2^53 − 1 = 9,007,199,254,740,991 (0x1FFFFFFFFFFFFF). The reason is precision, not arbitrary policy: a JavaScript number is an IEEE-754 double-precision float, which can represent every integer exactly only up to 2^53 − 1. Past that point consecutive integers start to collide onto the same float — 2^53 and 2^53 + 1 are indistinguishable — so any base conversion above the limit would silently return an off-by-one or worse. Rather than hand you a wrong answer, the converter throws a RangeError when a value would exceed the safe-integer ceiling. For arbitrary-precision work (cryptographic constants, 64-bit hashes, very large IDs) you want a BigInt-based tool or a language with native 64-bit integers; the safe-integer ceiling here covers the full unsigned 32-bit range and most of the unsigned 53-bit range, which is enough for memory addresses, IPv4 math, color values, and permission bits.

Question 1

Why does computer science use hexadecimal instead of just binary?

Accepted Answer

Binary (base 2) is the native language of digital circuits — every transistor is either on (1) or off (0). But binary is verbose: the 32-bit value 255 requires 8 binary digits (11111111), and a 32-bit memory address like 3,221,225,472 requires 32 binary digits (11000000000000000000000000000000). Reading, writing, and comparing these values mentally is error-prone. Hexadecimal (base 16) maps cleanly onto binary because 16 = 2⁴: each hexadecimal digit represents exactly 4 binary bits. The 8-bit value 11111111 in binary is 0xFF in hex (F = 1111, F = 1111). The 32-bit memory address above is 0xC0000000 in hex — 8 hex digits vs. 32 binary digits, but each hex digit maps directly to 4 bits without any conversion ambiguity. Per Randall Hyde, The Art of Assembly Language: 'Hexadecimal is the perfect human-readable encoding for binary data because the power-of-2 relationship means you never lose or gain precision in the conversion.' Hex is used in: memory addresses and pointers (where every bit matters), network protocol byte layouts (Ethernet frames, IP headers, TCP segments), color codes in CSS (#FF5733), SHA/MD5 hash values, CPU register values in debugger output (gdb, LLDB, WinDbg), x86 instruction encodings in disassemblers (objdump, IDA Pro). Octal (base 8) is still seen in Unix file permissions (chmod 755 = rwxr-xr-x = 111 101 101 in binary) because 8 = 2³ and each octal digit maps to exactly 3 binary bits — the three permission bits (read/write/execute) per user class.

Question 2

What's two's complement and why do computers use it for negative numbers?

Accepted Answer

Two's complement is the standard representation for signed integers in all modern computer hardware. In an N-bit two's complement system: non-negative integers 0 through 2^(N-1)−1 have the same binary representation as their unsigned values. The most significant bit (MSB) is the sign bit: 0 = positive, 1 = negative. Negative integers are encoded as 2^N minus the absolute value. Example for 8-bit: +5 = 00000101, −5 = 2⁸ − 5 = 251 = 11111011. The key property that makes two's complement superior to alternatives: addition and subtraction work identically for signed and unsigned values with the same hardware circuit. The CPU's adder does not need to know whether it's computing 251 + 5 (unsigned) or −5 + 5 (signed) — the bit operations are identical, and the carry bit handles overflow in both cases. Historical alternative: sign-magnitude representation (one sign bit, N-1 magnitude bits) was used on some early computers. It required separate addition and subtraction circuits because you had to check the sign bit first. It also had two representations of zero (+0 and −0), which complicated equality checks. Two's complement range for common bit widths: 8-bit: −128 to +127 (signed), 0 to 255 (unsigned). 16-bit: −32,768 to +32,767 (signed), 0 to 65,535 (unsigned). 32-bit: −2,147,483,648 to +2,147,483,647 (signed), 0 to 4,294,967,295 (unsigned). 64-bit: −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807 (signed). Per Kernighan and Ritchie, The C Programming Language §2.9: 'The behavior is implementation-defined for signed integer overflow' in C — this is why Rust chose defined wrapping semantics instead.

Question 3

What's the difference between signed and unsigned integers?

Accepted Answer

An unsigned integer uses all N bits to represent non-negative values from 0 to 2^N − 1. An 8-bit unsigned integer can hold values 0 through 255. A signed integer uses two's complement to represent values from −2^(N-1) to 2^(N-1) − 1. An 8-bit signed integer can hold values −128 through +127. The bit pattern 11111111 (all ones) means 255 if you interpret it as unsigned, or −1 if you interpret it as signed (two's complement: 2⁸ − 255 = 1). The interpretation is entirely up to the program — the CPU stores and operates on the same bits regardless. This is why C has separate types (uint8_t vs. int8_t, uint32_t vs. int32_t) and why Rust has u8 vs. i8, u32 vs. i32. Practical implications: Overflow: unsigned overflow wraps (255 + 1 = 0 for 8-bit unsigned). Signed overflow is undefined behavior in C/C++ (the compiler can optimize assuming it doesn't happen) and a panic in Rust debug builds. Comparison: comparing a signed and unsigned integer of the same size can produce unexpected results because the bit pattern for −1 signed (all ones) is greater than 2,147,483,647 when interpreted as unsigned. This is a source of real bugs in C code: `if (signed_int < unsigned_int)` may silently convert the signed to unsigned before comparing. Bit shifts: right-shifting an unsigned value fills with 0 (logical shift). Right-shifting a signed negative value in most C implementations fills with 1 (arithmetic shift, preserving sign), though the behavior is implementation-defined. In Java, `>>>` is logical right shift and `>>` is arithmetic right shift.

Question 4

Why do IPv4 addresses use dotted decimal instead of a single number?

Accepted Answer

An IPv4 address is a 32-bit unsigned integer. 192.168.1.1, for example, is 32 bits = 4 bytes. In decimal, 192.168.1.1 = (192 × 2²⁴) + (168 × 2¹⁶) + (1 × 2⁸) + 1 = 3,232,235,777. In hex, it is 0xC0A80101. Dotted-decimal notation (developed by ARPANET in the 1970s) was chosen because it reflects the IPv4 address structure: 4 octets (bytes) with each byte in the range 0–255. This structure matters for subnetting — the routing decision of whether a packet stays on the local network or goes to a gateway depends on which bits are the 'network prefix' (determined by the subnet mask). Reading 0xC0A80101 and understanding that C0 = 192 (the first octet) requires hex literacy, while 192.168.1.1 is immediately parseable by anyone who has read an IP address before. The subnet mask in dotted decimal (e.g., 255.255.255.0 or /24 in CIDR notation) clearly shows the boundary: the first three octets (24 bits) are the network, the last octet (8 bits) is the host. In binary: the /24 mask is 11111111.11111111.11111111.00000000. CIDR notation (/24, /16, /8) counts how many leading 1-bits are in the mask — a format that only makes sense if you understand the binary representation of the address. This calculator converts IPv4 addresses to their 32-bit decimal, hex, and binary representations so you can verify subnet math, understand the boundaries, and debug routing tables.

Question 5

How does base64 encoding work and when do I use it?

Accepted Answer

Base64 encoding, defined in RFC 4648, converts arbitrary binary data (bytes) into a string of 64 printable ASCII characters: A-Z (26), a-z (26), 0-9 (10), + and / (2) = 64 characters total. Each base64 character represents 6 bits (since 2⁶ = 64). Three bytes of binary data (24 bits) become 4 base64 characters (4 × 6 = 24 bits). The encoding process: take 3 bytes (24 bits), split into 4 groups of 6 bits each, map each group to the base64 alphabet (A=0, B=1, ..., Z=25, a=26, ..., z=51, 0=52, ..., 9=61, +=62, /=63). If the input is not a multiple of 3 bytes, pad the last group with zeros and add = padding characters (one = if 1 byte was padded, == if 2 bytes were padded). Size overhead: base64 output is 4/3 the size of the input (33% larger). URL-safe base64 (RFC 4648 §5) replaces + with - and / with _ to avoid issues in URLs and HTTP headers. When to use base64: embedding binary data in JSON (JSON only supports UTF-8 strings, not raw bytes); Data URIs for images in HTML/CSS (`data:image/png;base64,...`); Basic Authentication in HTTP headers (`Authorization: Basic base64(username:password)`); encoding email attachments (MIME multipart, base64 part); JWT (JSON Web Tokens) encode header and payload as URL-safe base64. When NOT to use base64: storing data in a database (use BYTEA in PostgreSQL, BLOB in MySQL, or a dedicated binary column — base64 wastes 33% space and makes indexing harder); transmitting data in binary protocols (HTTP/2, gRPC, WebSocket binary frames all handle raw bytes); anywhere where storage size or transmission time matters significantly.

Question 6

What's a bitwise AND/OR/XOR and how do I compute it by hand?

Accepted Answer

Bitwise operations operate on individual bits of integer values, applied independently to each bit position. Bitwise AND (&): each output bit is 1 only if the corresponding bits in BOTH operands are 1. Use case: masking (isolating specific bits). Example: 0b11001010 & 0b00001111 = 0b00001010 (extract the lower 4 bits). In hex: 0xCA & 0x0F = 0x0A. Bitwise OR (|): each output bit is 1 if the corresponding bit in EITHER operand (or both) is 1. Use case: setting specific bits. Example: 0b11001010 | 0b00001111 = 0b11001111 (set the lower 4 bits). Bitwise XOR (^): each output bit is 1 if the corresponding bits DIFFER. Use case: toggling bits, simple checksums, encryption primitives. Example: 0b11001010 ^ 0b00001111 = 0b11000101 (toggle the lower 4 bits). XOR property: A ^ A = 0, A ^ 0 = A — used in the classic 'swap without a temp variable' trick: `a ^= b; b ^= a; a ^= b;`. Bitwise NOT (~): flips all bits. In an N-bit system, ~x = 2^N − 1 − x. For a signed 32-bit int: ~0 = −1 (all ones in two's complement). Left shift (<<): shifts bits left, multiplying by 2 per shift. 1 << 8 = 256 = 0x100. Right shift (>>): for unsigned, fills with 0 (logical shift, divides by 2). For signed, behavior is implementation-defined in C but arithmetic (fills with sign bit) on most CPUs. Common patterns: check if bit n is set: `(value >> n) & 1`. Set bit n: `value | (1 << n)`. Clear bit n: `value & ~(1 << n)`. Toggle bit n: `value ^ (1 << n)`. These operations run in a single CPU instruction on all modern architectures.

Question 7

Why do memory addresses use hex?

Accepted Answer

Memory addresses in computer systems are binary values — pointers are N-bit unsigned integers (32-bit on 32-bit systems, 64-bit on 64-bit systems) that identify a location in the process's address space. Hex is used to display them because: (1) The power-of-2 relationship: every 4 bits = 1 hex digit. A 64-bit pointer = 16 hex digits. Reading 0x00007FFF5FBFF678 is manageable; reading the same value in binary (64 ones and zeros) is not. (2) Alignment visibility: memory allocators and hardware requirements often align data to power-of-2 boundaries (4-byte aligned, 8-byte aligned, 16-byte aligned, 4096-byte page-aligned). Alignment is immediately visible in hex: 0x7FFF5FBFF000 ends in three zeros, indicating it's page-aligned (4096 = 0x1000). In decimal, 140734799806464 offers no such visual cue. (3) Byte boundary clarity: hex naturally groups into bytes (every 2 hex digits = 1 byte). A 4-byte integer in memory occupies 8 hex digits; the byte boundaries are obvious. (4) Protocol and format specifications: network protocols (Ethernet, IP, TCP), file format specs (ELF, PE, DWARF), and CPU architecture manuals (Intel SDM, ARM Architecture Reference) all specify bit fields and byte offsets in hex. Being fluent in hex is a prerequisite for reading these documents. Per Randall Hyde, The Art of Assembly Language §1.4: 'One of the first things assembly language programmers learn is to think in hexadecimal. Not because it's more natural than decimal, but because the relationship between hex and binary is so direct that thinking in hex is effectively thinking in binary with much less visual noise.'

Question 8

What's the maximum value of a 32-bit unsigned integer and why does it matter?

Accepted Answer

The maximum value of a 32-bit unsigned integer is 2³² − 1 = 4,294,967,295. In hex: 0xFFFFFFFF. In binary: 32 ones. This value appears in several important contexts that software developers encounter regularly: IPv4 address space: the maximum IPv4 address (255.255.255.255) is 0xFFFFFFFF = 4,294,967,295 — representing the broadcast address. The total IPv4 address space is 2³² = 4,294,967,296 unique addresses. Array and string size limits in C: on 32-bit systems, size_t is a 32-bit unsigned integer, so the maximum size of an array or string is 4,294,967,295 bytes (approximately 4 GiB). Signed 32-bit maximum (for comparison): 2³¹ − 1 = 2,147,483,647 = 0x7FFFFFFF — this is the maximum positive value for a signed 32-bit integer, and it is the Unix timestamp for 2038-01-19T03:14:07Z (the Y2K38 limit). Loop counter overflow: a common bug in C is using a signed int for a loop counter that approaches INT_MAX. If the counter is compared to an unsigned value of similar magnitude, the signed-to-unsigned conversion can make the loop run forever. Memory map ranges: 32-bit systems have a virtual address space from 0x00000000 to 0xFFFFFFFF (4 GiB total). On Windows 32-bit, the upper 2 GiB (0x80000000–0xFFFFFFFF) is reserved for the kernel; user-mode processes have 2 GiB of address space by default. POSIX mmap flags: MAP_FAILED = (void*)−1 = all bits set = 0xFFFFFFFF on 32-bit systems.

Question 9

Can I enter a number with a 0x, 0b, or 0o prefix?

Accepted Answer

Yes. The converter accepts an optional source-base prefix and strips it when it matches the base you selected: 0x for hexadecimal, 0b for binary, and 0o for octal — in either case (0xDEAD and 0xdead both work). Digit-group underscores and surrounding whitespace are also ignored, so you can paste 1111_1111 or 0xFF_FF directly the way you would write a numeric literal in Rust, Python, or modern C++. If a prefix does not match the selected base — say you paste 0b1010 while the base selector is on hexadecimal — the leading 0 and b are treated as ordinary digits, and because b is a valid hex digit (11) you'll get a value, so double-check the base selector matches your prefix. This calculator never silently coerces: an illegal digit for the chosen base raises a clear error instead of dropping the bad character.

Question 10

How large a number can this converter handle, and why is there a limit?

Accepted Answer

Inputs are capped at JavaScript's largest safe integer, Number.MAX_SAFE_INTEGER = 2^53 − 1 = 9,007,199,254,740,991 (0x1FFFFFFFFFFFFF). The reason is precision, not arbitrary policy: a JavaScript number is an IEEE-754 double-precision float, which can represent every integer exactly only up to 2^53 − 1. Past that point consecutive integers start to collide onto the same float — 2^53 and 2^53 + 1 are indistinguishable — so any base conversion above the limit would silently return an off-by-one or worse. Rather than hand you a wrong answer, the converter throws a RangeError when a value would exceed the safe-integer ceiling. For arbitrary-precision work (cryptographic constants, 64-bit hashes, very large IDs) you want a BigInt-based tool or a language with native 64-bit integers; the safe-integer ceiling here covers the full unsigned 32-bit range and most of the unsigned 53-bit range, which is enough for memory addresses, IPv4 math, color values, and permission bits.

Question 11

Why is the hex output lowercase?

Accepted Answer

Lowercase is what JavaScript's Number.prototype.toString(radix) emits, and that is what ECMA-262 specifies for radices 2 through 36 — the digits above 9 are the lowercase letters a through z. The converter renders the canonical lowercase form (deadbeef rather than DEADBEEF) so the output is stable and matches what you'd get from String(n.toString(16)) in your own code. On input, case does not matter: 0xDEADBEEF, 0xdeadbeef, and DeadBeef all parse to the same value. The lowercase-vs-uppercase choice is purely cosmetic — many C debuggers and the Intel SDM print uppercase hex, while Unix tooling and most languages default to lowercase — so if your downstream system expects uppercase, apply .toUpperCase() to the result.

Number Base Converter

What this means

Worked example

Frequently asked questions

Show the math / algorithm