What Base64 Actually Does to Your Bytes (and Why It's Not Encryption)

Every developer pastes a data:image/png;base64,iVBORw0K... blob into their CSS at some point, decodes a JWT to see what's inside, or hits a "Basic " auth header and wonders why the password is just... sitting there. Base64 is everywhere in web development, and it's quietly misunderstood by a lot of people who use it daily. Here's what it actually is, what it costs, and the one mistake that shows up in production security reviews.

Base64 is a costume for binary, not a lock

The core idea: Base64 turns arbitrary binary data into plain ASCII text so it can travel through channels that only expect text. Email bodies, URLs, JSON values, HTML attributes, and HTTP headers were all designed for text — hand them raw bytes (a PNG, a 0x00, a UTF-16 string) and something downstream mangles or drops them. Base64 re-expresses those bytes using only safe, printable characters that nothing along the way will touch.

The alphabet is exactly 64 characters: A–Z, a–z, 0–9, plus + and /. That's 26 + 26 + 10 + 2 = 64. There's also =, used only for padding (more on that below). Sixty-four characters is the whole trick — and it's where the name comes from.

Critically: Base64 is encoding, not encryption. It provides zero secrecy. Anyone can reverse it instantly — there's no key. If you've ever "hidden" a credential by Base64-encoding it, you've hidden nothing; you've just made it slightly less obvious to a human skimming, and completely obvious to literally any tool. We'll come back to why that matters.

The 3-bytes-to-4-characters math

Here's the mechanism, and it explains everything else about Base64's behavior.

A byte is 8 bits. A Base64 character represents 6 bits (because 2⁶ = 64, exactly enough to index the alphabet). The least common multiple of 8 and 6 is 24, so Base64 works in groups of 3 bytes (24 bits) → 4 characters (4 × 6 bits):

Input:   3 bytes   = 24 bits
Regroup: 4 × 6-bit chunks
Output:  4 Base64 characters

Take the bytes for Cat (0x43 0x61 0x74), line up the 24 bits, slice them into four 6-bit numbers instead of three 8-bit ones, and look each up in the alphabet → Q2F0. That's the entire algorithm: regroup bits from 8-wide to 6-wide and map to characters.

Two consequences fall out of this immediately.

1. Base64 makes data ~33% bigger. Every 3 bytes in become 4 characters out, so output is 4/3 ≈ 1.33× the input size. That's the price of text-safety. A 3 MB image becomes ~4 MB of Base64 text. This is exactly why you don't Base64 large assets into your HTML/CSS — you inflate the payload by a third and make it un-cacheable as a separate file. You can watch this overhead directly by pasting text into a Base64 encoder/decoder and comparing input vs output length.

2. Padding (=) fills the gaps. If your data isn't a clean multiple of 3 bytes, the last group is short. Base64 pads the output to a multiple of 4 characters using =: one = means the last group had 2 bytes, two == means it had 1 byte. So a trailing == is normal and expected — it's not corruption, it's the encoder telling the decoder how many real bytes the final group held.

The URL-safe variant you'll meet in JWTs

Standard Base64 uses + and /. Both are a problem in URLs (/ is a path separator) and in filenames. So there's a second flavor, Base64URL, that swaps:

• + → -
• / → _
• and usually drops the = padding entirely

This is what you see inside a JSON Web Token. A JWT is just three Base64URL strings joined by dots: header.payload.signature. Decode the first two segments and you get plain JSON — which is the second reason people get burned. A JWT payload is readable by anyone, because Base64URL isn't encryption either. The signature protects against tampering, not against reading. Never put secrets in a JWT payload. If you want to eyeball what's in one, decode the segment and run it through a JSON formatter to pretty-print the claims.

Where Base64 genuinely earns its keep

• Data URIs — inlining a tiny icon or font directly in CSS/HTML (url(data:image/svg+xml;base64,...)) to save an HTTP request. Good for small assets only, because of the 33% tax.
• Email attachments (MIME) — the original use case; SMTP is a text protocol, so binary attachments are Base64-encoded (historically wrapped at 76 characters per line).
• HTTP Basic auth — Authorization: Basic <base64(user:pass)>. This is why Basic auth over plain HTTP is dangerous: the credentials are encoded, not encrypted, so anyone on the wire reads them. Always pair it with HTTPS.
• Embedding binary in JSON/XML — JSON has no binary type, so byte blobs (small images, hashes, keys) get Base64'd into string fields.

The mistakes that show up in code review

• Treating Base64 as security. Encoding ≠ encryption ≠ hashing. If the goal is secrecy, you need actual cryptography; if it's integrity, you need a hash or signature.
• Base64-ing huge files. The 33% bloat plus the memory cost of holding both the binary and its text form will hurt. Stream or upload the raw bytes instead.
• Mixing the two alphabets. Feeding standard Base64 (+, /) into a Base64URL decoder (or vice versa) fails or corrupts. Match the variant to the context — URLs and JWTs want Base64URL.
• Panicking over =. Trailing padding is normal. Some systems strip it (and re-add it on decode); that's fine as long as both ends agree.

The takeaway

Base64 is a simple, elegant bit-regrouping scheme: 8-bit bytes re-sliced into 6-bit chunks so binary can ride through text-only pipes. It costs you a third more size and buys you universal compatibility — a great trade for small assets, MIME, and JSON, a bad one for big files. The single thing to burn into memory: it is not a security mechanism. Anything Base64-encoded is plainly readable by anyone who cares to look.

Next time you see a data: URI or a dotted JWT, you'll know exactly what those characters are — and that you could decode them yourself in a second.

Author bio: Quan Nguyen builds free, no-signup developer tools at calculators.im, including a Base64 encoder/decoder and a JSON formatter.