Base64 vs Hex

Binary-to-text encoding works by grouping bits and translating those groups into characters from a fixed alphabet.

Hex (Base16) splits each 8-bit byte into two 4-bit nibbles. Each nibble is translated into a single character from the hexadecimal alphabet (0-9, A-F). For example, the byte `01001011` (decimal 75) is split into `0100` (4) and `1011` (B), resulting in the string "4B". Since every byte is translated into exactly two characters, Hex encoding requires no padding and maintains a static length multiplier.

Base64 groups binary data in 24-bit chunks (3 bytes). It splits these 24 bits into four 6-bit segments. Each 6-bit segment represents a value from 0 to 63, which is mapped to a character in the Base64 alphabet. For example, three binary bytes are represented as four Base64 characters, creating a 4:3 length multiplier.

Binary-to-Text Mapping:
- Original Data: [ 01001011 ] [ 11010010 ] (16 bits / 2 bytes)
- Hex (Base16):  [ 0100 ] [ 1011 ] [ 1101 ] [ 0010 ] -> "4BD2" (4 chars)
- Base64:        [ 010010 ] [ 111101 ] [ 001000 ] [ padding ] -> "S9I=" (4 chars)

The spatial overhead of an encoding scheme has a direct impact on storage requirements and network transmission bandwidth.

Hex has a spatial overhead of exactly 100%. If you encode a 1 MB image using Hex, the resulting string will be 2 MB. This makes Hex highly inefficient for transporting large binary files over web channels.

Base64 has a spatial overhead of roughly 33.3% (plus up to two padding characters). A 1 MB image encoded in Base64 will result in a string of roughly 1.33 MB. While still larger than raw binary, Base64 is 50% more efficient than Hex. For web applications embedding files (such as images, PDF attachments, or CSS assets) directly inside JSON payloads, HTML documents, or stylesheets, Base64 is the default standard.

Because Base64 processes data in 3-byte blocks, it must handle cases where the input data is not a multiple of 3. If there is only 1 byte remaining, the encoder appends 4 bits of zero-padding and outputs two Base64 characters followed by two padding characters (`==`). If there are 2 bytes remaining, it appends 2 bits of zero-padding and outputs three characters followed by one padding character (`=`).

Standard Base64 uses the `+` and `/` characters. In URL query parameters or routing structures, these characters have special meanings (e.g. `+` is parsed as a space, and `/` splits directories). To prevent transport corruption, developers use "URL-Safe Base64," which replaces `+` with `-`, `/` with `_`, and strips the trailing padding `=` characters. Hex does not require padding or URL normalization because its alphabet consists entirely of standard numbers and letters.

// Base64 vs Hex encoding in Node.js
const buffer = Buffer.from("Hello Developer!");

const hexString = buffer.toString('hex');
console.log(hexString); // "48656c6c6f20446576656c6f70657221" (32 chars)

const base64String = buffer.toString('base64');
console.log(base64String); // "SGVsbG8gRGV2ZWxvcGVyIQ==" (24 chars)

Both Hex and Base64 encoding are fast operations, but Hex has a slight edge in simplicity. Hex encoding only requires simple bit-shifting and mask operations to extract nibbles, followed by an array lookup. Modern CPUs can optimize this process using SIMD (Single Instruction Multiple Data) registers, allowing them to encode gigabytes of data per second.

Base64 requires slightly more complex bit-packing math (joining bits from adjacent bytes to form 6-bit values). However, modern runtimes compile both operations to native binary routines. In Node.js, `Buffer.toString('base64')` and `Buffer.toString('hex')` run at speeds where CPU overhead is rarely a bottleneck for standard web apps.

While Hex and Base64 are the most common binary-to-text encoding systems, developers also utilize other base systems depending on the constraints of their transport medium. Base32 (RFC 4648) uses a 32-character alphabet, offering a middle ground in spatial overhead (~60% overhead) but completely avoiding case-sensitivity and confusing numbers. It is commonly used in MFA seed values (TOTP) and DNS names.

Base58 is a specialized encoding scheme popularized by Bitcoin for wallet addresses. It removes non-alphanumeric characters (+ and /) as well as visually ambiguous letters (0, O, I, and l) to prevent human errors during manual copying. Base85 (or Ascii85) offers even lower spatial overhead (~25% overhead) by using a larger 85-character set, and is frequently used in PDF file structures and git binary diff patches. However, standard Base64 and Hex remain the most widely supported in general web protocols.