Home / Guides / Hashes vs Encryption

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