Tools mentioned in this article
Open the browser-based tool while you read and try the workflow immediately.
“We store passwords in Base64” — that sentence describes a serious security misunderstanding. Encoding, hashing and encryption all transform a string into another form, but their purposes are completely different, and mixing them up leads to data leaks and broken designs.
This article sorts the three out with a comparison table and concrete examples, so you can pick the right one for each situation.
The answer up front: how the three differ
| Purpose | Reversible? | Needs a key? | Examples | |
|---|---|---|---|---|
| Encoding | Represent data in another format | Yes (by anyone) | No | Base64, URL encoding |
| Hashing | Produce a fixed-length one-way fingerprint | No | No | SHA-256, HMAC |
| Encryption | Keep data secret; only authorized parties can restore it | Yes (with the key) | Yes | AES, RSA |
The takeaways: encoding provides zero secrecy, hashing cannot be reversed, and encryption is the only mechanism designed to keep secrets.
Encoding: transformation for compatibility, not secrecy
Encoding merely rewrites data in a different representation. No key, no password — anyone can reverse it. It provides no confidentiality whatsoever.
Base64, for instance, exists to carry binary data or special characters safely as text:
Hello, World! →(Base64 encode)→ SGVsbG8sIFdvcmxkIQ==SGVsbG8sIFdvcmxkIQ== looks random, but paste it into a Base64 converter and anyone can restore the original instantly. URL encoding — for carrying special characters in URLs — belongs to the same family.
Common misuse: Base64-ing an API key or password and considering it “hidden” is dangerous. Base64 is not encryption and contributes nothing to secrecy.
Hashing: a one-way fingerprint
A hash computes a fixed-length digest from input data — strictly one-way. The same input always produces the same digest, but the original data cannot be recovered from it.
password123 →(SHA-256)→ ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94fChange the input even slightly and the output changes completely. These properties make hashing right for:
- Password storage: store the hash instead of the plaintext, and compare hashes at login (in practice with a salt and bcrypt/Argon2).
- Integrity checks: compare file or message hashes to detect tampering.
- Signatures: HMACs and JWT signatures guarantee data hasn’t been altered.
Try SHA-256 or HMAC in the hash generator and watch the output transform completely as you edit the input.
Key point: irreversibility is the essence of hashing. That’s exactly why it suits password storage — and why it’s wrong for anything where you need the original data back.
Encryption: reversible secrecy protected by a key
Encryption transforms data into an unreadable form using a key, such that only holders of the correct key can decrypt it. Unlike encoding, it can’t be reversed without the key; unlike hashing, it can be reversed with it. This is the only mechanism that actually keeps secrets.
- Symmetric encryption (AES, …): the same key encrypts and decrypts. Fast; used for data at rest.
- Public-key encryption (RSA, …): encrypt with the public key, decrypt with the private key. Used for key exchange and digital signatures.
HTTPS, database encryption at rest, and protecting confidential files are all encryption territory. Key management — not leaking keys, storing them properly — directly determines the security you get.
Quick decision table
| What you want to do | What to use |
|---|---|
| Carry special characters safely in URLs or JSON | Encoding (Base64 / URL encoding) |
| Store passwords safely | Hashing (bcrypt / Argon2, salted) |
| Verify a file hasn’t been tampered with | Hashing (SHA-256) |
| Keep data secret but recoverable later | Encryption (AES / RSA) |
| Protect traffic from eavesdropping | Encryption (TLS/HTTPS) |
| Verify a token hasn’t been altered | Hash-based signature (HMAC / JWT) |
Classic mistakes
- “Encrypting” with Base64: as above — zero secrecy. Never for confidential data.
- Storing passwords encrypted: decryptable means one leaked key exposes every password. Passwords never need decrypting, so a salted hash is the correct design.
- Plain SHA-256 for passwords: too fast, so brute force is cheap, and rainbow tables apply. Use salts plus a deliberately slow algorithm like bcrypt or Argon2.
- Rolling your own crypto: use battle-tested standard libraries. Homemade cipher implementations are almost always vulnerable.
Summary
Similar names, opposite roles. Encoding changes the representation (no secrecy), hashing is an irreversible fingerprint, encryption is key-protected reversible secrecy. With that distinction in place, the choices become natural: hash your passwords, encrypt your traffic, encode your URLs. To see the behavior hands-on, try the Base64 converter, hash generator and JWT decoder.
FAQ
Why isn’t Base64 encryption?
Base64 uses no key and its transformation rules are public, so anyone can reverse it instantly. With no element of secrecy, it is classified as encoding (a change of representation), not encryption. It cannot be used to hide confidential information.
Should passwords be stored hashed or encrypted?
Hashed. Passwords never need to be decrypted, so a one-way hash (salted bcrypt or Argon2) is appropriate. Encrypted storage means a leaked decryption key exposes every password at once.
Is a hash truly impossible to reverse?
Computationally, the original data cannot be derived from the digest. However, common passwords can be matched via precomputed (rainbow) tables — which is why per-user salts and deliberately slow, brute-force-resistant algorithms matter.
Are JWT tokens encrypted?
A typical JWT (a signed JWS) is signed, not encrypted. The payload is merely Base64URL-encoded, and anyone can read it with a JWT decoder. The signature only detects tampering — so never put secrets directly in a JWT. When confidentiality is required, use encryption (JWE).