Base64 is encoding, not encryption: what to know

You see a long string of letters and digits, maybe ending in one or two equals signs, and it looks like a secret. It is not. That is Base64, and it hides nothing. Anyone can turn it back into the original in one step. I care about this because I keep finding secrets that someone Base64’d and then treated as safe, and that mistake is how the secret got out.

TL;DR: Base64 rewrites binary data as plain text so it can travel through systems built for text, like email and URLs. It maps every 3 bytes to 4 printable characters, which grows the data by about 33% and uses no key at all. Decoding is instant. It is a transport format, not encryption. Never use it to protect a password, token, or any secret.

What Base64 is for

Computers store images, files, and keys as raw bytes. But plenty of systems were built to carry text and only text. Email bodies, URLs, JSON fields, HTML, and CSS all expect printable characters, and raw binary can break them or get mangled on the way through.

Base64 fixes that. It re-expresses any bytes using a safe set of 64 printable characters: the letters A to Z and a to z, the digits 0 to 9, and two extras (+ and /). Sixty-four characters is where the name comes from. The output is text that any text-based system will carry intact. That is why you can embed a small image directly in a stylesheet as a data URL, why an attachment can ride inside a plain-text email, and why tokens get encoded this way.

Think of Base64 as the shipping box that lets binary cargo travel on roads paved for text. The box keeps the contents from breaking in transit. It is not a safe, and it was never meant to be.

How it actually works

Here is the mechanism, because it explains both why Base64 is bigger than the input and why it is trivial to reverse.

Base64 reads your data 3 bytes at a time. Three bytes is 24 bits. It slices those 24 bits into four groups of 6 bits each. Each 6-bit group is a number from 0 to 63, and each of those 64 values maps to exactly one character in the Base64 alphabet. So 3 bytes in, 4 characters out. Every time.

That 3-to-4 ratio is the whole story on size. Four divided by three is about 1.33, so Base64 output runs roughly 33% larger than what you fed it. If your input length is not a clean multiple of 3, Base64 pads the last group with = signs to fill the block out to 4 characters, which is what those trailing equals signs are for. Add optional line breaks that some tools insert, and the output can be a hair larger still.

Nothing here involves a secret. The alphabet is a published standard, the same for everyone on earth. Any decoder reverses the map with no key, no password, no permission.

Run it yourself

Take the word cat. That is 3 bytes, so it becomes exactly 4 Base64 characters:

cat  ->  Y2F0

On any Mac or Linux terminal:

printf 'cat' | base64
# Y2F0

Now decode it back. Notice there is no password prompt:

printf 'Y2F0' | base64 -d
# cat

The original comes straight back. Try it with something that feels sensitive, and the point lands harder:

printf 'password123' | base64
# cGFzc3dvcmQxMjM=

cGFzc3dvcmQxMjM= looks cryptic. It is not. Anyone who pipes it through base64 -d, or pastes it into a Base64 encoder and decoder at dev.hivly.net, gets password123 back with zero effort. The equals sign on the end is just padding, because password123 is 11 bytes and 11 is not a multiple of 3.

Why it is not encryption

Encryption and Base64 can look alike, because both produce output you cannot read at a glance. They work in opposite ways.

Encryption uses a secret key to transform data so that only someone with the matching key can reverse it. Without the key, the output is meaningless. The security rests entirely on the key staying secret.

Base64 has no key. It uses one fixed, published alphabet, identical for everyone, and the mapping is fully reversible by anyone who knows the standard. There is no secret, so there is nothing to keep an attacker out. Calling Base64 a code is like calling the alphabet a code. It is just a different way of writing the same information, readable by anyone who can read. You saw this above: decoding cat took no key and one command.

The mistake that leaks secrets

The dangerous version of this confusion is storing or sending a secret in Base64 and believing it is protected. A password, an API key, a session token: drop any of them into Base64 and the scrambled-looking output feels safe. So it ends up in a config file, a log line, a URL, or a database column that someone assumes is hidden. It is not hidden. Anyone who reads that string decodes it to the original in seconds, exactly like the password123 example.

This shows up constantly in tokens. A JWT is made of Base64-encoded parts, and its payload is right there for anyone to read. That is precisely why you must never put a secret in a JWT payload. The encoding is not protection. It is the opposite, because it is trivially reversible. Treat Base64 output as if it were ciphertext and you have published your secret while feeling like you locked it away.

The right mental model

Hold one rule and you will not get this wrong: Base64 changes the format, encryption changes the access.

Reach for Base64 when you need binary data to survive a text-only channel: embedding an image, attaching a file, carrying a token’s structure. Reach for real encryption, meaning a proper algorithm with a key you keep secret, whenever the goal is to stop someone from reading the contents.

The two work together, in order. Encrypt the secret first, which makes it unreadable without the key. Then, if you need to move that encrypted blob through a text channel, Base64 it for transport. Encrypt for secrecy, then encode for travel. Encoding alone, with nothing under it, protects nothing, no matter how cryptic the output looks.