The one-line summary
- Encoding: transforms data for compatibility — anyone can reverse it
- Encryption: transforms data for confidentiality — only someone with the key can reverse it
- Hashing: transforms data for integrity verification — cannot be reversed
Encoding
Encoding is a lossless transformation that changes the representation of data, not its meaning. It provides no security — anyone can decode it using the same scheme.
Examples:
- Base64: converts binary data to printable ASCII characters so it can travel safely in systems that only handle text (emails, JSON, URLs). Decode any Base64 string instantly with the free Base64 decoder.
- URL encoding: converts special characters to percent-encoded form (
%20for space) so they can appear safely in URLs. - HTML encoding: converts
<to<so it appears as literal text in HTML rather than being interpreted as markup.
The security mistake: storing Base64-encoded passwords in a database. Base64 is not security — it provides no confidentiality. Anyone with the encoded string can decode it in seconds.
Encryption
Encryption transforms data into ciphertext using a key. Without the correct key, the ciphertext is computationally impossible to reverse. With the correct key, the original data is fully recoverable.
Two main types:
- Symmetric encryption (AES): the same key encrypts and decrypts. Fast, used for bulk data — encrypted files, HTTPS session data, database encryption.
- Asymmetric encryption (RSA, ECDSA): a public key encrypts, a private key decrypts. Used for key exchange, digital signatures, SSL/TLS handshakes.
Use encryption when: data needs to be stored or transmitted confidentially and then recovered later — credit card numbers, private messages, files at rest.
Hashing
A hash function produces a fixed-length output from any input. It is one-way — you cannot reconstruct the original input from the hash. The same input always produces the same hash; different inputs produce different hashes (with negligible collision probability).
Examples: MD5 (broken), SHA-256, SHA-3, bcrypt, Argon2.
Use hashing when: you need to verify that something is what it claims to be, without storing the thing itself — passwords, file integrity, digital signatures.
The password hashing mistake: storing passwords as MD5 or SHA-256 hashes. These are designed to be fast — GPUs can test billions of guesses per second. Use bcrypt or Argon2 instead, which are deliberately slow. Generate a bcrypt hash with the free bcrypt tool.
The dangerous confusions
| Mistake | Why it's wrong |
|---|---|
| Storing Base64-encoded passwords | Base64 is encoding — anyone can decode it. Use bcrypt. |
| Using MD5 for password hashing | MD5 is a fast hash — GPU cracks it in seconds. Use bcrypt/Argon2. |
| Using SHA-256 for password hashing | SHA-256 is too fast for passwords. Use bcrypt/Argon2. |
| Treating encryption as hashing | If you need to recover the original data (sessions, tokens), use encryption. If you only need to verify, use hashing. |
Quick reference
| Operation | Reversible? | Key needed? | Use for |
|---|---|---|---|
| Base64 encoding | Yes | No | Data transport compatibility |
| URL encoding | Yes | No | URL parameter safety |
| AES encryption | Yes | Yes (secret key) | Confidential data storage/transport |
| RSA encryption | Yes | Yes (public/private key pair) | Key exchange, digital signatures |
| SHA-256 hash | No | No | File integrity, checksums |
| bcrypt hash | No | No | Password storage |
Summary
Encode for compatibility (Base64, URL encoding). Encrypt for confidentiality when you need to recover the data (AES, RSA). Hash for verification when you don't need to recover the data (SHA-256 for files, bcrypt for passwords). Using the wrong one is not a stylistic choice — it is a security vulnerability.