A developer once "encrypted" a database of passwords by Base64-encoding them before storage, reasoning that the values no longer looked like plaintext. When that database leaked, every password was recovered in seconds — Base64 is not encryption, it is not even trying to hide anything, and confusing it with encryption is exactly the kind of mistake that turns a minor breach into a catastrophic one.
Hashing, encoding, and encryption all transform data from one representation to another, and that surface similarity is precisely why they get confused. But they solve three completely different problems, and picking the wrong one for your goal doesn't just underperform — it can actively fail to provide the protection you think it does.
Direct Answer: Hashing is a one-way transformation used for verification and integrity — you can check that data matches a known hash, but you cannot reverse a hash back into the original input (that's the point: it's how password systems avoid ever storing the actual password). Encoding is a reversible, key-free transformation used purely to make data safe to transmit or store in a given format — Base64 turns binary data into ASCII text for email or JSON payloads, and anyone can decode it back with no secret required, because encoding was never designed to hide anything. Encryption is a reversible transformation that requires a secret key to reverse — it's the only one of the three designed to provide confidentiality, meaning data is genuinely unreadable to anyone without the key.
1. Hashing: One-Way, for Verification
A hash function takes an input of any size and produces a fixed-size output (a "digest"), and it is designed so that reconstructing the input from the digest is computationally infeasible. This makes hashing ideal for two jobs: verifying a password without ever storing it, and verifying a file hasn't been tampered with (checksums).
Input: "correct horse battery staple"
SHA-256: c3ea1...9f7b (64 hex characters, always this length)
Input: "Correct horse battery staple" (one letter capitalized)
SHA-256: 8a4f2...1c0d (completely different digest — the avalanche effect)
Because a hash can't be reversed, a login system never needs to store your actual password — it stores the hash, and on each login it hashes what you typed and compares digests. You can experiment with this directly using a hash generator to see how even a one-character input change produces a completely unrelated output.
2. Encoding: Reversible, No Security Purpose
Encoding exists to solve a compatibility problem, not a security problem: some transport channels (email, URLs, JSON strings) can't safely carry arbitrary binary bytes, so encoding maps that data into a safe character set.
Original (binary/text): Hello, World!
Base64 encoded: SGVsbG8sIFdvcmxkIQ==
Anyone can reverse this with zero secret knowledge — a Base64 encoder/decoder will decode that string right back to "Hello, World!" instantly. Base64 is used constantly and legitimately: embedding images in HTML/CSS as data URIs, encoding email attachments (MIME), and putting binary tokens into JSON or URLs safely. None of that is security — it is purely a format-compatibility step.
3. Encryption: Reversible, Requires a Secret Key
Encryption is the only one of the three built for confidentiality. Like encoding, it's reversible — but unlike encoding, reversing it requires a secret (a key), which is what makes the data actually protected rather than merely reformatted.
Plaintext: "Transfer $500 to account 44821"
Key: (kept secret, e.g. AES-256 key)
Ciphertext: 8f3a...e91c (unreadable without the key)
Decryption requires the same key (symmetric) or a matching private key (asymmetric)
Encryption comes in two flavors worth knowing: symmetric (one shared key encrypts and decrypts, e.g., AES) and asymmetric (a public key encrypts, only the matching private key decrypts, e.g., RSA) — TLS/HTTPS uses both, negotiating a symmetric session key using asymmetric cryptography.
4. The Decision Table
| Goal | Use | Reversible? | Needs a key? |
|---|---|---|---|
| Verify a password without storing it | Hashing (with salt) | No | No |
| Verify a file wasn't corrupted/tampered with | Hashing (checksum) | No | No |
| Safely embed binary data in text-only formats | Encoding (Base64, URL encoding) | Yes | No |
| Hide a value's meaning from anyone without permission | Encryption | Yes | Yes |
| Store credit card numbers, health records, secrets at rest | Encryption | Yes | Yes |
If your requirement is "nobody but the intended recipient should be able to read this," encoding never satisfies it — reaching for Base64 there is the exact mistake that made the opening example a real incident, not a hypothetical.
5. The Real-World Mistake, Generalized
The Base64-as-encryption mistake shows up in more disguises than password storage: developers sometimes Base64-encode an API key and put it in a public GitHub repo assuming it's "obscured," or encode a session token in a URL parameter believing that makes it tamper-proof. In every case, encoding provides zero confidentiality and zero integrity guarantees — it is purely a format transformation, fully and trivially reversible by design, and treating it as a security control is the recurring root cause behind this whole category of mistake.
Frequently Asked Questions
Is Base64 a type of encryption?
No. Base64 is encoding — it is fully reversible by anyone with no secret key required, and it exists to make binary data safe for text-only transport, not to hide information.
Can a hash be decrypted back to the original password?
No — hashing is intentionally one-way. A login system that "recovers" your forgotten password instead of making you reset it is a red flag that it may not be hashing passwords properly.
Why add a salt to a hash?
A salt (random data unique per user) prevents attackers from using precomputed rainbow tables to reverse common passwords in bulk, and ensures two users with the identical password get different stored hashes.
If I encrypt something, do I still need to hash it?
These serve different goals and are often combined: encrypt data you need to retrieve later (like stored files), hash data you only ever need to verify (like passwords) — encrypting a password you'll only ever compare, never retrieve, adds complexity without benefit.
Is MD5 or SHA-256 good enough for password hashing?
No — general-purpose hash functions like MD5 and SHA-256 are deliberately fast, which makes them poor for passwords specifically since attackers can brute-force them quickly; dedicated slow algorithms like bcrypt or Argon2 are the appropriate choice there.
References: RFC 4648 (Base64 encoding), NIST FIPS 180-4 (Secure Hash Standard), NIST SP 800-38A (encryption modes).
