Skip to content

← All writing

Base64 Isn't Encryption: What It Actually Does (and When to Use It)

· by Andergrove Software

If you remember one thing about Base64: it is encoding, not encryption. There is no key and no secret. Anyone can decode a Base64 string back to the original in one step, so Base64 hides nothing. People still reach for it to "obscure" a value and then get a nasty surprise. Base64 exists to move binary data through text-only channels safely, not to protect it.

Here is exactly what Base64 does, how the three-bytes-to-four-characters trick works, why it inflates size by a third, and what to use when you actually need secrecy. You can encode and decode anything in the Base64 encoder/decoder as you read.

The one-sentence truth

Base64 maps arbitrary bytes to a 64-character alphabet of plain text. It is fully reversible with no key: decode(encode(x)) returns x for everyone, always. Encryption is different: it transforms data with a key so that only someone holding the key can reverse it. Base64 has no key, so it provides zero confidentiality. Base64-ing a password or API key just makes it slightly less obvious to a human, not secret. (This is exactly why a JWT payload, which is Base64, is readable by anyone, see how JSON Web Tokens work.)

How it works: 3 bytes to 4 characters

Computers store data as bytes of 8 bits. Base64 regroups those bits into 6-bit chunks, because 2^6 = 64, and maps each chunk to one character from its alphabet: A-Z, a-z, 0-9, plus + and /.

  • Take 3 bytes, which is 24 bits.
  • Split them into four 6-bit groups.
  • Map each group to one of the 64 characters.

So every 3 input bytes become exactly 4 output characters. When the input is not a multiple of 3 bytes, Base64 pads the result with one or two = characters so the length is always a multiple of four. That padding is why Base64 strings so often end in = or ==.

A common variant, base64url, swaps + and / for - and _ so the result is safe in URLs and filenames. That is the version JWTs use.

Why it exists

Many channels were built for text, not raw bytes, and will mangle or choke on arbitrary binary. Base64 lets you carry binary through them intact:

  • Email attachments (MIME), because SMTP is a text protocol.
  • Embedding images in HTML or CSS via data: URIs.
  • Binary inside JSON or XML, which have no native byte type.
  • Storing keys or certificates in text config (PEM files are Base64).

In every case the goal is safe transport of bytes as text, never secrecy.

The 33% size penalty

Because 3 bytes become 4 characters, Base64 output is about 133% of the original size (4/3), before padding. That overhead is fine for small values but matters at scale: base64-ing large images directly into HTML bloats the page and defeats caching, because the bytes can no longer be cached as a separate file. Use it deliberately for small payloads, and link to real binary files when they are large.

What to use when you need secrecy

If the goal is to keep something confidential, you need encryption with a key, not encoding. For text you want to protect with a passphrase, the Andergrove AES Text Encryption tool encrypts and decrypts in your browser using AES. For proving a message has not been tampered with, you want a keyed hash (HMAC). Base64 is the wrong tool for both; it is for transport, full stop.

Try it

Paste text or upload a file in the Base64 encoder/decoder and watch it convert both ways instantly, entirely in your browser. Encode a short word, note the = padding, then decode it straight back to prove the point: anyone can. When you need actual secrecy, reach for AES encryption instead.