Base64 is not encryption
Three operations get tangled into one word, "scrambled", and the tangles fill breach reports: API keys "encrypted" with Base64 in a public config file, passwords "encrypted" with MD5 in a leaked database. Encoding, encryption and hashing differ in the only ways that matter — whether a key exists, and whether the trip back is possible at all. Untangling them takes one paragraph each.
Encoding: a costume change, public by design
An encoding translates data into a restricted alphabet so it can travel: Base64 turns bytes into letters, digits, + and / so a binary file survives email; Base64URL bends the alphabet for URLs and tokens; hex doubles bytes into characters a human can read. The defining facts are that the translation is standardised and keyless — the method is public, identical for everyone, and reversing it is not an attack but the feature. Paste any Base64 string into the decoder and out comes the original, every time, for everyone. This is why the format's presence in a security context is a finding, not a control. Kubernetes Secrets are the canonical example: the values sit in etcd Base64-encoded, which the documentation itself states is not encryption — anyone with read access to the manifest holds the plaintext one decode later. The same shape appears in CI configs with "encoded" registry passwords, in mobile apps with "encoded" API keys, and in the config file committed to the public repo where the author felt the string no longer looked like a credential. It did not stop being one.
Encryption: reversible, but only with the key
Encryption is the operation people usually mean: a transformation (AES-GCM, ChaCha20-Poly1305) that is public and standardised, parameterised by a key that is the only secret in the system. Without the key, reversal is computationally out of reach; with it, reversal is instant — that asymmetry is the entire product. Two tells separate real encryption from costume changes wearing its name. There is a key somewhere, managed as a secret in its own right; and the output differs between runs for the same input, because real schemes fold in randomness (a nonce or IV) — encrypt the same file twice and the ciphertexts differ, while Base64 of the same file is identical forever. When a vendor says data is "encrypted" and cannot point at the key or the algorithm, the word is doing marketing work. And when the "encryption" is a transformation implemented in the same code that ships to the user — the app contains both the scrambled key and the descrambler — the key's secrecy is theatrical: anyone with the binary has both halves, which is the double-Base64 fallacy in a trench coat.
Hashing: the one-way street, and its own confusions
A hash takes any input to a fixed-size fingerprint and offers no road back at all — not "hard to reverse", but designed so that reversal means guessing the input and checking. That one-wayness is the right tool for integrity (does this download match its published digest — compute it with the hash generator and compare) and the wrong-shaped tool, in its fast general-purpose form, for passwords. The breach-report phrase "passwords were encrypted with MD5" actually means hashed with MD5, and it is bad news precisely because hashing is guessable: MD5 runs at GPU billions-per-second, so a leaked unsalted MD5 column is a password list waiting one afternoon. Passwords demand the slow, salted specialists — bcrypt, scrypt, Argon2 — whose shapes the hash identifier recognises on sight. The third confusion is between hashing and the other two in the opposite direction: a hash offered as an "encrypted backup" or a digest stored where the original will be needed again. There is no decryption step coming, ever; the data is gone in every direction except comparison. Encoding you can undo with a web page, encryption you can undo with the key, hashing you can undo with luck and a weak password — know which one you are holding before you build on it. And when it is time to make a new secret rather than mangle an old one, generate it properly with the password generator: sampled from a real random source, stored in a manager, and never required to look scrambled to be safe.
Frequently asked questions
If Base64 is not encryption, why does everything use it?
Because transport, not secrecy, is the common problem. Email, URLs, JSON and config files are text systems; files, tokens and certificates are bytes. Base64 is the standard costume change that lets bytes travel through text systems intact — that is all it ever claimed to be. It became a security smell only when people started treating the unreadable output as protected output: it looks scrambled, so it feels secret. The scramble has no key, no randomness and no resistance — anyone can reverse it, instantly, which is the entire point of the format.
Is an MD5 "encrypted" password recoverable?
Not by reversing — hashing is one-way — but usually by guessing, which amounts to the same outcome. MD5 is fast, and a leaked MD5 database meets GPUs that try billions of candidate passwords per second; the common and human-shaped ones fall in minutes. That is why passwords are stored with bcrypt, scrypt or Argon2 (slow, salted, memory-hard) rather than any fast digest, and why "we encrypt passwords with MD5" in a breach disclosure means the passwords are effectively public. If you have inherited such a database, the migration path is to rehash on next login and force resets for the rest.
What about "double Base64" or Base64 plus a secret twist?
Still not encryption. Any fixed, keyless transformation — double encoding, reversing the string, ROT13, XOR against a constant baked into the code — is a puzzle with the solution published alongside it, in the code anyone can read. Real encryption is defined by the key being the only secret: the algorithm is public, standardised and reviewed (AES-GCM, ChaCha20-Poly1305), and everything except the key can be known. If your scheme’s secrecy depends on nobody looking at the method, it is obfuscation — fine for tidiness, fatal for credentials.