Base64 Explained: What It Is, and Why It Isn't Encryption

Computers store everything as bytes, and a byte can hold any of 256 values. Plenty of channels, though, were designed to carry text, not arbitrary bytes. Old email servers only reliably passed 7-bit ASCII. JSON and XML are text formats. A URL, an HTML attribute, or a copy-pasted string can be mangled by anything that isn't a printable character. Base64 solves this by re-expressing binary data using a limited, universally safe alphabet.

That alphabet has 64 symbols — the uppercase letters A to Z, the lowercase a to z, the digits 0 to 9, and two extras (a plus and a slash in the standard variant). Sixty-four is not arbitrary: it is exactly the number of distinct values you can represent with 6 bits (2 to the 6th power). Base64 chews through your data 6 bits at a time and maps each 6-bit chunk to one character from that table.

Because your data arrives in 8-bit bytes but leaves in 6-bit chunks, the numbers don't line up evenly. Base64 works on groups of 3 bytes (24 bits) at a time, splitting each group into 4 six-bit pieces. That 3-in, 4-out ratio is the source of both its structure and its size overhead, which we get to below.

Take the word hello. As bytes, those five characters are 104, 101, 108, 108, 111. Grab the first three bytes and write them out in binary: 01101000 01100101 01101100. That's 24 bits. Now re-slice the exact same bits into four groups of six: 011010, 000110, 010101, 101100 — which are the numbers 26, 6, 21, and 44.

Look each number up in the Base64 alphabet and you get a, G, V, s. So the first three bytes of hello become aGVs. The last two bytes (108, 111) are only 16 bits, one short of a full group. Base64 pads the missing bits with zeros to finish the last character, then appends an equals sign to mark that padding happened, giving bG8=. Put it together and hello encodes to aGVsbG8=. Decoding simply runs the whole process in reverse.

The equals sign at the end is padding, not data. Because Base64 always emits characters in blocks of four, a final block that started with only one leftover byte ends in ==, and one that started with two leftover bytes ends in a single =. That keeps the total length a clean multiple of four so a decoder knows exactly where the real bytes stop.

Encoding, encryption, and hashing get lumped together constantly, but they solve different problems. Encoding (Base64, URL encoding) is a public, reversible transformation for safe transport — no secret is involved and reversing it is expected. Encryption (AES, RSA) is reversible only if you hold the key, and its whole job is confidentiality. Hashing (SHA-256) is a one-way fingerprint used to verify integrity, not to hide or later recover the data.

Base64 sits firmly in the first bucket. There is no key to reverse it, because reversing it is the entire point. This is why an HTTP Basic Auth header is not secure on its own: the credentials Aladdin:open sesame become QWxhZGRpbjpvcGVuIHNlc2FtZQ==, which any observer can decode instantly. What actually protects those credentials is the HTTPS/TLS layer wrapped around the request, not the Base64 inside it.

JWTs make the same point. A JSON Web Token is three Base64URL-encoded parts joined by dots, and the header and payload are plain, readable JSON — paste any JWT into a decoder and you can read every claim. The cryptographic signature stops someone from tampering with those claims; it does nothing to hide them. The rule that falls out of all this: never put anything you wouldn't want read into a Base64 string, a JWT payload, or a client-side token.

Because Base64 turns every 3 bytes into 4 characters, the output is always about 4/3 the size of the input — roughly a 33% increase. A 1 MB file becomes about 1.33 MB of text. On top of that, the email (MIME) form of Base64 inserts a line break every 76 characters, adding a little more, and padding rounds small inputs up further.

That overhead is the reason Base64 is a poor fit for large payloads. It is also the catch with data URIs. Embedding a big image directly in your HTML or CSS as base64 both inflates it by a third and prevents the browser from caching that asset separately — the bytes get re-downloaded with the document every time instead of being served from cache as a standalone file. Inlining makes sense for tiny assets (a small icon, a critical above-the-fold sliver) where saving one request beats the size cost; it backfires on anything substantial.

When Base64 is genuinely too fat, the alternatives are either a more compact text encoding or, better, sending real binary over a channel that supports it. Here's how the common text encodings compare:

Base64 earns its keep whenever binary data has to travel through a text-only pipe. The classic cases are stable and worth knowing by name, and each comes with a caveat about when to reach for something else instead.

Reach for Base64 when the transport is genuinely text and the payload is modest. Reach for raw binary transfer, a URL to the asset, or streaming when the payload is large or performance-sensitive.

Every mainstream environment has Base64 built in. On the command line, macOS and Linux ship a base64 utility; the -n on echo matters because it prevents a trailing newline from sneaking into your input. In the browser, btoa and atob exist but have a Unicode trap (covered in the FAQ) — for anything beyond plain ASCII, encode the bytes yourself. Node.js and Python handle UTF-8 correctly out of the box.

One decoding gotcha across all of them: most decoders tolerate surrounding whitespace and newlines but will reject an unexpected character or, sometimes, missing padding. If a decode fails, check first for a standard-versus-URL-safe mismatch (+ and / versus - and _) or a stripped equals sign.

The variant you'll meet most often after standard Base64 is Base64URL. It encodes identically but swaps the two problem characters: + becomes -, / becomes _, and the = padding is frequently omitted. This matters because a raw + or / breaks inside URLs (where + can mean a space) and filenames. If a token decodes fine in one place and errors in another, a standard-versus-URL-safe mismatch is the usual culprit.

A second trap is Unicode in the browser. The built-in btoa expects each character to fit in a single byte, so handing it an emoji or most non-English text throws a range error. The correct approach is to turn the string into UTF-8 bytes first with a TextEncoder, then Base64-encode those bytes — or lean on Node's Buffer, Python, or a tool that does UTF-8 for you.

Finally, don't confuse Base64 with a checksum or a validator. It changes how bytes are represented; it does nothing to verify that they arrived intact or unaltered. If you need to confirm a download or a payload wasn't corrupted or tampered with, that's a job for a hash like SHA-256, not for Base64.