Binary 101: How Computers Store Data and Why Base64 Exists

Every file on your computer, every packet on the network, every pixel on your screen — at the bottom, it's all just 0s and 1s. Understanding binary isn't just a computer science exercise. It's the key to understanding why encodings like Base64 and hexadecimal exist, and why they make the tradeoffs they do.

Bits, Bytes, and Why We Group Them

A single bit holds one of two values: 0 or 1. That's not very useful by itself. Group 8 bits together and you get a byte, which can represent 256 different values (2⁸). That's enough for all the letters, numbers, and symbols you need — or a number from 0 to 255.

// One byte can represent:
00000000 = 0   (decimal)
01000001 = 65  (decimal) = 'A' (ASCII)
11111111 = 255 (decimal)

// Multiple bytes together:
01001000 01101001 = "Hi" (two ASCII characters)

But raw bytes are terrible for text-based systems. A byte with value 0 (NUL) will terminate a C string. A byte with value 13 might be interpreted as a carriage return. If you need to send binary data through a system that expects text, you need an encoding that translates arbitrary bytes into safe, printable characters.

Base64: Packing 3 Bytes into 4 Characters

Base64 solves the problem by encoding 3 bytes (24 bits) into 4 ASCII characters (6 bits each). Here's how it actually works:

Input: "Man" (3 bytes)
M = 01001101 (77)
a = 01100001 (97)
n = 01101110 (110)

// Concatenate all 24 bits:
01001101 01100001 01101110

// Split into 6-bit groups:
010011  010110  000101  101110
  ↓       ↓       ↓       ↓
 19      22       5      46    (decimal)

// Map to Base64 alphabet (A-Z, a-z, 0-9, +, /):
 19 → T
 22 → W
  5 → F
 46 → u

Output: "TWFu"

Want to visualize this for your own data? Our Base64 to Binary converter shows the raw bit representation of any Base64 string and our Base64 to Hex converter shows it in hexadecimal — both ways to peer under the hood of the encoding.

Why Base64 Adds ~33% Overhead

Every 3 bytes of input produce 4 bytes of output. That's a 4/3 = 1.33x size increase. This is the fundamental tradeoff of Base64: you get portability through text-based systems at the cost of a 33% size increase.

Hex doubles the size; binary representation increases it 8x. Base64 is the most space-efficient text encoding that uses only printable ASCII characters. That's why it won — not because it's perfect, but because it hits the sweet spot between portability and overhead.

Hex: When You Need to See the Raw Bytes

While Base64 is efficient for transport, hexadecimal is the go-to format when you need to actually read the bytes. Each byte becomes exactly two hex characters, making it trivial to see individual byte boundaries:

Bytes:    77     97     110
Hex:      4D     61     6E
ASCII:     M      a      n

// In hex, you can see each byte clearly
// In Base64 ("TWFu"), byte boundaries are obscured

Binary: Seeing the 0s and 1s

Converting Base64 to raw binary (the actual 0s and 1s) is mostly educational — it helps you understand what's actually happening at the bit level. But it's also useful for visualizing patterns, checking bit flags, and understanding protocol headers.

Try It Yourself

The best way to understand these encodings is to see them in action:

• Base64 to Binary — See your Base64 string as raw 0s and 1s
• Base64 to Hex — View the hexadecimal representation of each byte
• Base64 to ASCII — See the decoded ASCII character codes with a byte-by-byte breakdown

Each tool shows you a different lens on the same underlying binary data. Together, they make the invisible visible.