How Base64 Encoding Works

Base64 is the bridge between two worlds that don't speak the same language: raw binary data and text-only channels. Every time you see an image inlined in a web page, a token in a URL, or an email attachment, Base64 is probably doing the translation — and the math behind it is simpler than it looks.

Why Base64 exists

A lot of the internet's plumbing was designed for text. Email protocols, HTTP headers, JSON fields, and URLs all assume printable characters, and many of them choke on raw bytes: a null byte, a stray control character, or a byte that happens to mean "end of message" can corrupt the whole payload.

Base64 solves this by representing any sequence of bytes using only 64 safe, printable characters: A-Z, a-z, 0-9, +, and /. The result can pass through any text-only channel intact, and the receiver can decode it back into the exact original bytes. Nothing is compressed and nothing is hidden — the data is carried, not transformed.

The 3-bytes-to-4-characters trick

Base64 works on groups of 3 bytes. Three bytes is 24 bits, and 24 bits splits evenly into four groups of 6 bits. Each 6-bit value (0 to 63 — hence "base 64") indexes one character of the alphabet. That gives the core size rule:

every 3 bytes of input  →  4 characters of output

Worked example, encoding the string Cat. Each character is one byte: C = 67, a = 97, t = 116:

C = 01000011   a = 01100001   t = 01110100
regroup the 24 bits into sixes:
010000 | 110110 | 000101 | 110100
   16  |   54   |    5   |   52
   Q   |    2   |    F   |    0    →  "Q2F0"

Index 16 in the alphabet (A=0, B=1, …) is Q; index 54 is the digit 2; index 5 is F; index 52 is 0. So Cat encodes to Q2F0 — and decoding Q2F0 reverses every step exactly.

Padding and the = signs

What if the input isn't an exact multiple of 3 bytes? Output length must still be a multiple of 4, so the final group is padded with = characters. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus a single =. The classic example: Hello is 5 bytes, which encodes as SGVsbG8= — one padding character. An input of 7 bytes would end in ==.

The padding carries no data of its own; it just tells the decoder where the real bits stop. Many decoders accept input with the padding stripped off, but the standard form always pads out to a multiple of 4.

The 33% size cost

Six bits of data per 8-bit character means every byte you encode costs 8/6 ≈ 1.33 characters. The exact formula for the encoded length:

encoded length = 4 × ceil(input bytes / 3)

So Base64 output is always about 4/3, or 133%, of the original size — roughly one third bigger. This matters when you inline a file: a 300 KB image becomes roughly 400 KB once encoded, and if it is embedded as a data URI (data:image/png;base64,...), all of that weight lands in the HTML itself.

The trade-off can still be worth it. A data URI saves an extra HTTP request and can't fail to load separately from the page. But for anything large, or reused across many pages, a normal image file that the browser can cache independently is usually the better deal.

Base64 is not encryption

One misconception deserves its own section: Base64 provides zero security. There is no key and no secret — the alphabet is public, and every step is trivially reversible. Encoding a password in Base64 "hides" it exactly as well as writing it backwards. Use Base64 for transport compatibility, and use real encryption when you need secrecy.

It also has a few standard variants worth recognizing: URL-safe Base64 swaps + and / for - and _ so tokens can sit inside URLs unescaped; MIME (email) Base64 wraps output at 76 characters per line; and most decoders silently ignore whitespace. Same math, different cosmetics.

Try it yourself

Encode and decode text in your browser with the Base64 Encoder — try Cat first and check you get Q2F0. Inline an image file as a data URI with the Image Base64 Encoder and watch the size grow by about a third. To see the same bytes in the other classic text encoding, the Hex Encoder renders each byte as two hex digits instead of packing six bits per character. And for a list of strings at once, the Base64 Batch tool processes the whole batch in one pass.