Base64 Is Not Encryption: A Field Guide to What It Actually Does

The Two-Second Decryption

A few years back I was asked to audit a small internal tool another contractor had built for a client. It synced configuration between two services, and somewhere in the handoff it needed to authenticate. I opened the config file and found a field cheerfully named apiSecret, holding a long string ending in ==. The developer who built it had told the client, verbatim, that the secret was "encoded so it can't be read in plain text."

I copied the string, opened my browser console, and typed atob("..."). Two seconds later the live production API secret was sitting in my terminal in clear, readable ASCII. No key. No password. No cracking. The "encoding that can't be read" was Base64, and Base64 is not a lock — it is a font.

This is the single most expensive misconception I run into, and it costs companies real breaches. So let me walk through exactly what Base64 does, what it does not do, and the one mental test that will keep you from making the same mistake.

The 6-Bit Mechanics: Why Base64 Exists At All

Base64 was never designed to hide anything. It was designed to move binary data through channels that only safely handle text — email bodies, URLs, JSON string fields, HTTP headers. Those channels can choke on raw bytes like 0x00 or 0xFF. Base64 solves that by re-expressing arbitrary bytes using only 64 "safe" printable characters.

Here is the mechanism. Computers store data in 8-bit bytes. Base64 ignores byte boundaries and instead regroups the bits into chunks of 6 bits each. Why 6? Because 2⁶ = 64, and 64 distinct values map cleanly onto the alphabet: A–Z (values 0–25), a–z (26–51), 0–9 (52–61), then + (62) and / (63).

The arithmetic works in groups of 3 bytes:

• 3 bytes = 24 bits
• 24 bits ÷ 6 = exactly 4 output characters

So every 3 input bytes become 4 output characters. That ratio is why Base64 inflates data by roughly 33% — you are spending 4 characters to carry what was 3 bytes. When the input length is not a multiple of 3, the output is padded with = characters to keep the 4-character alignment. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus =.

Let me hand-walk the canonical example, the string Man:

Char:        M           a           n
ASCII:       77          97          110
Hex:         0x4D        0x61        0x6E
Binary:      01001101    01100001    01101110

Regroup into 6-bit chunks:
             010011  010110  000101  101110
Decimal:     19      22      5       46
Alphabet:    T       W       F       u

Result:  "Man"  ->  "TWFu"

Notice there is no == here because Man is exactly 3 bytes, mapping to exactly 4 characters with no padding. You can confirm this yourself in any browser console:

btoa("Man");        // -> "TWFu"
atob("TWFu");       // -> "Man"

btoa("Hi");         // -> "SGk="   (2 bytes -> 3 chars + one "=")
atob("SGk=");       // -> "Hi"

btoa ("binary to ASCII") encodes; atob ("ASCII to binary") decodes. Run them in sequence and you always get your original input back. That round-trip is the whole point — and the whole problem.

Why So Many Engineers Keep Confusing The Two

If this mistake were rare, it would not be worth a guide. But I see it from junior developers and grey-bearded architects alike, and the reasons are remarkably consistent. Understanding why the confusion happens is the best inoculation against repeating it.

The first culprit is purely visual. A Base64 string and a chunk of real ciphertext look almost identical to the human eye — both are dense, opaque blocks of letters and digits with no spaces and no obvious meaning. Worse, that trailing == looks important. It reads, to an untrained eye, like a checksum or a signature, some piece of cryptographic machinery that proves the data has been processed by something serious. In reality those equals signs are just padding to round the length up to a multiple of four. They carry no secret and protect nothing, but they feel like security theater in the most literal sense.

The second culprit is the "unreadable string" heuristic. People reason backwards: real secrets look scrambled, this looks scrambled, therefore this must be a secret. That syllogism is broken at the second step, because "scrambled to a human" and "scrambled without a key" are entirely different properties. A telephone number written in Morse code looks unreadable too, yet anyone with the chart recovers it instantly. Base64 is exactly that — a chart anyone can download, baked into every browser and every standard library on the planet.

The third culprit is loose vocabulary, and it spreads the confusion faster than either of the others. Developers say "encrypt the config" when they mean "Base64 it," or "the token is hashed" when it is merely encoded, or "obfuscated" as if that were a synonym for "secured." Documentation, Stack Overflow answers, and even some libraries use these words interchangeably. Once the wrong word is in someone's head, the wrong mental model follows, and they ship a system that "encrypts" secrets that anyone can read. Precise terms are not pedantry here; they are the difference between a credential being protected and a credential being publicly legible. If you take one habit from this section, make it this: never let the word "encoded" and the word "encrypted" sit next to each other in your head as if they were close cousins. They are not even in the same family.

The Core Distinction: Encoding Versus Encryption

Here is the line that the contractor in my opening story never internalized.

Encoding is a public, reversible transformation with no secret involved. Anyone holding the encoded data holds the original data — they only need to know the format, which is published in RFC 4648. There is no key. atob is built into every browser on earth. Encoding answers the question "how do I represent these bytes as safe text?" It answers nothing about confidentiality.

Encryption is a keyed transformation designed to be irreversible without that key. The whole security model rests on a secret that the attacker does not have. Without the key, the output is computationally infeasible to reverse.

The contrast becomes concrete with the Web Crypto API, which ships in every modern browser. Here is real AES-GCM encryption:

// Encrypt with AES-GCM using Web Crypto
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 },
  true,
  ["encrypt", "decrypt"]
);

const iv = crypto.getRandomValues(new Uint8Array(12)); // fresh per message
const plaintext = new TextEncoder().encode("Man");

const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  plaintext
);

// ciphertext is an ArrayBuffer of unreadable bytes.
// Without `key` AND `iv`, no one can recover "Man".

Look at what crypto.subtle.encrypt demands that btoa never asks for: a key and an iv (initialization vector). Those are the secret inputs. Hand someone the ciphertext alone and they get nothing. Hand someone a Base64 string and they get everything. That is the entire difference, and it is not a matter of degree — it is categorical.

A useful way to hold this in your head: Base64 changes the clothing of your data; encryption changes its soul. The clothing fools nobody who looks twice.

What About Stacking Encodings Or Mixing In ROT13?

Once people accept that a single pass of Base64 hides nothing, a tempting follow-up appears: what if you encode it twice? Or three times? What if you Base64 the string, run it through ROT13, then Base64 it again, and maybe reverse the characters for good measure? Surely a stack that deep is hard to unwind.

It is not, and the reason is the heart of this whole guide. None of those steps takes a key. Each transformation in the chain is a publicly defined, deterministic operation, which means each one is reversible by anyone who recognizes it — and recognizing them is trivial. Base64 has a giveaway alphabet and frequently a = tail. ROT13 is a fixed shift any cryptanalyst spots in seconds. Stacking reversible operations only produces a longer reversible operation; it adds steps, not secrecy. An attacker simply peels the layers one at a time, and each peel is a function call. Wrapping plaintext in ten coats of paint does not make it a safe — it makes it a slightly more annoying afternoon for someone who will still succeed.

The key word is, almost literally, key. Security does not come from how many transformations you apply or how unusual they look. It comes from one input that the attacker does not possess. A single round of genuine AES with a secret key defeats every adversary without that key; a thousand rounds of Base64, ROT13, and byte-reversal defeat no one, because there is nothing to not possess. Obfuscation can raise the effort bar a notch against a bored, casual snooper, and occasionally that is an honest goal — but call it obfuscation, never encryption, and never trust it to guard anything whose exposure would actually hurt.

Real Misuses I Keep Finding

1. HTTP Basic Auth treated as secure. The Authorization: Basic header is literally base64(username:password). So Authorization: Basic YWRtaW46aHVudGVyMg== decodes instantly to admin:hunter2. Basic Auth is acceptable only over HTTPS, where TLS encrypts the entire request in transit. Over plain HTTP it is plaintext-equivalent — every router between client and server can read the credentials by running one atob call. The Base64 wrapper provides zero protection; the transport layer does all the work.

2. localStorage "obfuscation." I have reviewed several apps that Base64-encode a user object or session blob before dropping it into localStorage, under the belief that it stops tampering. It stops nothing. Anyone can open DevTools, read the value, decode it, edit the role field from user to admin, re-encode, and write it back. Base64 in storage is a speed bump made of paint.

3. Base64-encoding passwords before storing them. This is the one that makes me wince hardest. Passwords should never be reversibly stored at all — not encoded, and ideally not even encrypted. They should be run through a slow, salted password hash so that even a full database leak does not reveal them. Base64 is reversible by definition, so storing btoa(password) is functionally identical to storing the password in cleartext. If you came here looking to "protect" passwords, what you actually want is a one-way hash, and you can experiment with hashing on the hash generator to see that, unlike Base64, there is no atob that brings the original back.

4. Hiding user_id in a URL parameter. A pattern I have flagged more than once: an endpoint takes something like ?ref=dXNlcl9pZD00Mg==, the developer assuming the opaque-looking string keeps the underlying value private. Decode it and you get user_id=42. From there it is one keystroke to try user_id=43, re-encode, and request another customer's record. That is a textbook IDOR (Insecure Direct Object Reference), and the Base64 wrapper does not slow it down at all — it merely advertises that there is a number to increment. If an identifier must not be guessed or tampered with, it needs a real, server-side authorization check or a signed, unguessable token, not a costume.

5. The "encrypted backup" that is just a Base64 dump. I once received an export labeled an "encrypted backup" of a small database. It was a single enormous Base64 blob, and one atob turned the entire thing back into readable JSON — names, emails, the lot. Nobody had lied on purpose; the person who built the export genuinely believed that turning bytes into a wall of letters constituted encryption. The lesson repeats: if there was no key on the way in, there is no key needed on the way out, and "backup" plus "unreadable-looking" does not add up to "encrypted."

See The Reversibility With Your Own Eyes

The fastest way to internalize that Base64 hides nothing is to watch it round-trip something visual. Take any small PNG, get its Base64 string, and paste it into the Base64 to image converter. The picture reappears, pixel-perfect, with no key requested anywhere. If a key were involved, that decode would be impossible without it. The fact that the image simply materializes is the proof: the so-called "encoded" data was your real data the entire time, just wearing a different alphabet.