Three technical words get swapped around so freely - In news coverage, in vendor marketing, even in developer documentation - That entire security failures trace back to the confusion. A company says user data was "encrypted" when it was merely Base64-encoded. A developer "hashes" API keys that later need to be read back, or "encrypts" passwords that never should be recoverable at all. Encryption, hashing, and encoding solve three different problems, and the fastest way to evaluate any security claim is knowing which of the three is actually being described.
The one-paragraph version
Encryption transforms data so it can be read again - But only with a secret key. Hashing transforms data into a fixed-size fingerprint that mathematically cannot be turned back into the original. Encoding transforms data into a different format for compatibility, with no secret involved - Anyone can reverse it instantly. A locked box, a fingerprint, and a translation. Everything else is detail.
Encoding: a translation, not a lock
Encoding rewrites data in another alphabet so it survives transport or storage. Base64 is the everyday example: it turns arbitrary bytes into 64 safe text characters so binary data can ride inside things built for text - Email attachments, JSON payloads, URLs, certificate files. Hex, URL-encoding (%20 for a space), and UTF-8 are all the same species.
The defining property: decoding requires no secret. The "key" is the publicly documented format itself. Paste cGFzc3dvcmQxMjM= into our Base64 tool and it decodes to password123 before you finish blinking - And so can every attacker, script, and browser extension on Earth.
Yet Base64'd secrets keep showing up where encryption was needed: credentials in config files and mobile apps, tokens in URLs, "obfuscated" API keys in client-side JavaScript. Security scanners specifically hunt for Base64-shaped strings precisely because developers keep mistaking a costume for armor. If a vendor tells you data was "encoded for security," you've learned the data was not protected at all.
Encryption: reversible, gated by a key
Encryption scrambles data such that reversing it requires a specific secret key. Done right - Say AES-256 in GCM mode - The ciphertext is indistinguishable from random noise, and the only feasible way back is the key. Try it interactively with our AES-256 encryptor: the same sentence encrypted twice even produces different ciphertext, because a random nonce is folded in each time.
Encryption comes in two families:
- Symmetric (AES, ChaCha20): one key both locks and unlocks. Fast - Hardware-accelerated gigabytes per second - And used for disk encryption, vault storage, WiFi, and the bulk of TLS traffic.
- Asymmetric (RSA, elliptic-curve): a public key locks, a private key unlocks. Slower, but it solves key delivery between strangers - It's how a TLS handshake agrees on session keys with a server you've never met, after which symmetric encryption takes over.
The correct use cases share one trait: someone legitimate needs the original data back. Files, messages, backups, database fields, password-manager vaults. That last one matters - Your vault is encrypted, not hashed, because you obviously need your passwords back out. The entire security question then collapses into key management: where the key lives, who can reach it, and what it was derived from.
Hashing: one-way on purpose
A hash function chews any input into a fixed-length digest - 256 bits for SHA-256, always, whether you hash one word or a terabyte. Three properties make it cryptographic: the same input always gives the same digest; finding an input for a given digest is computationally infeasible; and any tiny change to the input scrambles the whole output. There is no key and no way back - Irreversibility isn't a limitation, it's the entire point. Run a few strings through our MD5 generator and watch a one-character change avalanche the whole digest (then remember MD5 itself is broken for security use - Its collision resistance fell in 2004).
Hashing answers the question "is this the same data?" without storing the data:
- Password verification. The canonical use. The site stores a hash; at login it hashes what you typed and compares. A database thief gets fingerprints, not passwords. Passwords must never be encrypted instead - Encryption implies a key exists that reveals every user's password at once, and implies the company can read yours. Our MD5 vs SHA-256 vs bcrypt guide covers why password hashing additionally needs to be slow, unlike general-purpose hashing.
- Integrity checks. Download a file, hash it, compare with the published digest - Any tampering shows instantly.
- Deduplication and fingerprinting of files, certificates, and forensic evidence.
One nuance separates competent implementations from breach headlines: plain hashing isn't enough for passwords. Fast hashes invite brute force at billions of guesses per second, and identical passwords produce identical hashes - The flaw that rainbow tables were built to exploit until per-user salts shut them down. Password storage needs a salted, deliberately expensive algorithm like Argon2id or bcrypt. Same concept as hashing, tuned for a hostile world.
If someone legitimate needs the data back: encrypt. If you only ever need to check a match: hash. If no secret is involved at all: it's encoding, and it protects nothing.
Side by side
| Encoding | Encryption | Hashing | |
|---|---|---|---|
| Reversible? | Yes, by anyone | Yes, with the key | No, by design |
| Secret involved | None | Key | None (salt is not secret) |
| Output size | Grows with input | ≈ input size | Fixed (e.g. 256 bits) |
| Purpose | Compatibility, transport | Confidentiality | Verification, integrity |
| Examples | Base64, hex, URL-encoding | AES-256-GCM, ChaCha20, RSA | SHA-256, Argon2id, bcrypt |
| Right for stored passwords? | Never | No - Recoverable is a bug | Yes - Salted and slow |
| If the mechanism leaks | Nothing was hidden anyway | Safe until the key leaks | Safe until guessed offline |
Real-world failures from mixing them up
The taxonomy sounds academic until you meet the breach reports:
- Adobe, 2013. 153 million accounts leaked with passwords encrypted (3DES) instead of hashed - Same key for everyone, no salts, and password hints stored beside them. Identical passwords produced identical ciphertext, letting crackers solve the dataset like a giant crossword puzzle. Hashing with per-user salts would have made that impossible.
- Base64 "protection." A perennial finding in mobile-app audits: credentials or tokens Base64-encoded in code or config and described as obfuscated. Decode time: zero seconds.
- Unsalted fast hashes. LinkedIn's 2012 leak of unsalted SHA-1 hashes was cracked at industrial scale - Right category (hashing), wrong species (fast and unsalted).
The pattern holds so reliably that you can grade a company's security maturity from its breach disclosure vocabulary. "Passwords were hashed with bcrypt" - Competent. "Passwords were encrypted" - Worrying, and possibly Adobe redux. "Data was encoded" - No protection existed.
Why users should care at all
You can't choose how a service stores your credentials, but this vocabulary changes how you act. It tells you what a breach notice actually means, and it explains the two habits that make storage failures survivable: unique passwords per site (so one bad implementation doesn't cascade) and real length and randomness (so even a fast, unsalted hash of your password resists guessing longer than the attacker's patience). Strong input is the one variable you fully control in someone else's storage scheme.
FAQ
Is Base64 a form of encryption?
No. Base64 is an encoding - A public, keyless format change that anyone can reverse instantly. It exists so binary data can travel through text-only channels, not to hide anything. If a product describes Base64 as encryption or "obfuscation for security," treat everything else it claims with suspicion.
Why are passwords hashed instead of encrypted?
Because nobody legitimate ever needs your password back - The site only needs to verify a match at login. Encryption would mean a decryption key exists somewhere that reveals every password in the database at once, and that the company could read yours on demand. Hashing removes that capability entirely: even administrators can only check guesses, not recover originals.
Can a hash ever be reversed?
Not mathematically - But it can be guessed. Attackers hash billions of candidate passwords and compare results; if your password is common, its hash is effectively a lookup away. That's why hash strength for passwords depends on the algorithm being slow and salted, and why long random passwords stay safe even when weak ones in the same database fall.
What are encryption and hashing used for together?
Constantly - They're teammates, not rivals. TLS encrypts your traffic and uses hashes to fingerprint certificates and verify integrity. A password manager encrypts your vault with a key derived via hashing from your master password. Digital signatures hash a document, then encrypt the hash with a private key. Most real systems interleave all three primitives, each doing the one job it's built for.
How can I tell what a website does with my password?
Directly, you usually can't - Storage practices are invisible from outside. Warning signs help: a site that emails you your actual password, enforces short maximum lengths, or forbids special characters is signaling weak practices. Otherwise, assume the worst and act accordingly: unique, long, random credentials per site limit any single site's mistakes to that site alone.