Base64 is not encryption, and it never was

Base64 is probably the most misread thing in everyday computing. It looks scrambled, so it gets treated as though it hides something. It hides nothing at all, and confusing the two is one of the ordinary ways a secret becomes public.

What Base64 is for

Most of the plumbing we use only carries text safely. An email header, a URL, a JSON string, an HTML attribute, a log line, a config file — all text, and all of them have characters that mean something structural: a quote, an ampersand, a newline, a null byte. Raw binary contains those values at random. Put a PNG straight into a JSON string and the JSON breaks.

Base64 is the standard fix. It rewrites arbitrary bytes using only 64 characters that every text channel agrees to leave alone: 26 uppercase letters, 26 lowercase, ten digits and two more symbols. Nothing else appears in the output, which is exactly why the output survives the journey.

The mechanism is plain arithmetic. Take three bytes, which is 24 bits, and re-cut those same 24 bits into four groups of six. Six bits is a number from 0 to 63, so each group selects one of the 64 characters. Three bytes in, four characters out, so the encoded form is about a third larger than the input. When the input is not a multiple of three bytes the last group is short, and the encoder appends one or two = characters so a decoder knows how much of that final group was real.

A round trip you can check

The word gg is two bytes. Two is not a multiple of three, so there is one padding character: gg encodes to Z2c=.

Now something less innocent, of the kind that genuinely sits in configuration files. The line DB_PASSWORD=hunter2 encodes to REJfUEFTU1dPUkQ9aHVudGVyMg==.

Paste that second string into any decoder and the original line comes straight back. What did you have to supply in order to read it? Nothing. No key, no password, no account, no permission. Decoding Base64 is not breaking anything — it is finishing the operation. The encoder and the decoder are two halves of one publicly specified transformation, and everybody has both halves.

So a password, an API key or a token that has been Base64-encoded is public to anyone who can see it. It is not protected, and it is not obscured. It has been written down in a slightly less familiar alphabet.

Why the mistake is so easy to make

Partly because the output is unreadable at a glance, and we quietly take unreadable as a proxy for protected. Partly because Base64 keeps company with genuinely security-shaped things. HTTP basic authentication puts a Base64 string in a header, but the encoding is there to move awkward characters safely, not to guard them; TLS is what protects that header on the wire. Certificates and private keys are distributed in Base64 form too, but the private key is secret because of what it is, not because of how it was typed out.

Where this actually bites

• A credential encoded in a config file and committed, on the reasoning that it no longer looks like a password.
• A token in a URL. URLs get logged by proxies, servers and analytics, and they land in browser history and in shared links.
• A screenshot or a screen share of a terminal, a request or an editor. Anything visible is readable, and a still image is enough.
• An encoded string in front-end JavaScript or a mobile app bundle, treated as hidden. Anything shipped to a device belongs to whoever holds the device.
• A support ticket or a chat message where the encoded blob was pasted instead of the plain text, in the belief that this was the careful thing to do.

Three different jobs, three different words

Encoding is an agreed, reversible way to represent data, reversible by anyone, by design. Base64 and percent-encoding are encodings. Encryption is reversible only for someone holding a key, and the key is the whole point. Hashing is one-way: it produces a fingerprint, and there is no reverse operation. These three are not weak, medium and strong versions of one another. They answer different questions, and picking the wrong one is not a small error.

If the requirement is that someone must not read a value, the requirement is encryption — or better, not putting the value there at all: a secret store, an environment variable injected at deploy time, a token that expires. And if a credential has been sitting in encoded form somewhere other people could see it, the honest assumption is that it was seen. The fix for that is to rotate it, not to encode it again.

The tool

The Base64 Encode tool takes UTF-8 text in and gives ASCII out, and runs entirely in your browser, so what you paste is not uploaded anywhere. Use it for the job Base64 was built for: getting bytes through a channel that only speaks text. Not for keeping anything quiet.