Hashes vs Encryption: What Developers Need to Know
Hashes are one-way. Encryption is two-way. Confusing them leads to broken security. Here is how to use each correctly.
Hashes Are One-Way
A hash function turns input of any size into a fixed-size fingerprint. Same input always gives the same hash. You cannot reverse a hash to get the original. Use hashes for integrity (checksums, content-addressing) and, with care, for password verification (see below).
Encryption Is Two-Way
Encryption scrambles data so only someone with the key can unscramble it. Encrypt to protect confidentiality; decrypt with the key to recover the original. Base64 is neither hashing nor encryption; it is encoding.
MD5 and SHA-1 Are Broken
MD5 and SHA-1 have practical collision attacks: attackers can find two different inputs with the same hash. Do not use them for security: no signatures, no password hashing, no integrity in adversarial settings. They are fine for non-security checksums (e.g. file deduplication, cache keys).
Use SHA-256 (or Stronger)
SHA-256 is the default for new work: signatures, HMACs, content addressing. SHA-384 and SHA-512 offer a larger security margin. Our Hash Generator supports all of these so you can compare outputs.
Algorithm picker
| Algorithm | Good for | Avoid for |
|---|---|---|
| MD5 | Non-security checksums, dedup keys | Security integrity, signatures |
| SHA-1 | Legacy non-security checksums | New security work |
| SHA-256 | Integrity, signatures, content IDs, HMAC | Raw password hashing |
| SHA-384/512 | Higher security margin, long-term systems | Raw password hashing |
Passwords: Do Not Hash Raw
Raw MD5 or SHA-256 of passwords is dangerous. Use bcrypt, scrypt, or Argon2. They are slow by design and include salt. If you must use SHA-256 for passwords, use a proper key derivation function (e.g. PBKDF2, scrypt) with a salt and many iterations. Never store unsalted hashes.
Password hashing checklist
- Use Argon2 (preferred), bcrypt, or scrypt
- Use a unique salt per user (generated randomly)
- Use a slow configuration (cost/iterations) appropriate for your system
- Store only the hash output and parameters; never store plaintext passwords
- Use a pepper only if you can protect it (e.g. HSM/secret manager)
Integrity and Signatures
Hash the data, then sign the hash. Recipients verify by hashing and comparing. Use SHA-256 or better. For HMAC (authenticated integrity), use SHA-256. Avoid MD5/SHA-1 for any security-sensitive integrity checks.
HMAC vs plain hash
A plain hash proves that two copies of data match. It does not prove who created it. If an attacker can modify the data, they can also recompute the hash. Use HMAC when you need integrity plus authentication (shared secret).
// Node.js (HMAC-SHA256)
import crypto from 'node:crypto';
const mac = crypto.createHmac('sha256', secret).update(message).digest('hex'); Content-addressed storage
Hashes are great identifiers when you want the ID to be derived from the content. Git commit objects, build artifacts, caches, and dedup pipelines all rely on this property. SHA-256 is a common choice for new systems.
Quick sanity check
- Need to recover the original data? Use encryption.
- Need to detect changes? Use a hash (SHA-256 for security contexts).
- Need to ensure only someone with a secret could have produced it? Use HMAC.
- Storing passwords? Use a password hashing KDF (Argon2/bcrypt/scrypt).
Where Base64 fits
Base64 is encoding, not security. It is often used to transport binary hashes (or signatures) in JSON or URLs. If you need to decode/encode Base64 safely, see Base64 Encoding Explained.
When SHA-1 still shows up
You may still encounter SHA-1 in legacy systems and protocols, or in contexts where security properties are not relied upon (for example, older tooling). For new designs, prefer SHA-256 or stronger.
Use the Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hashes. All processing in your browser.
Open Hash Generator