Hashing vs Encryption vs Encoding

Three different things

Encoding, encryption and hashing get used interchangeably in conversation and mean completely different things in practice. Confusing them produces real vulnerabilities.

The one-line version: encoding is for machines that expect a particular format, encryption is for keeping secrets from people who lack the key, hashing is for proving something has not changed.

Encoding: not security at all

Encoding transforms data into a different representation so it survives a channel that would otherwise mangle it. There is no key and no secret — the algorithm is public and reversing it is trivial.

Base64:  'password' -> cGFzc3dvcmQ=
URL:     'a b&c'    -> a%20b%26c
Hex:     'Hi'       -> 4869

Base64 exists because some channels are text-only: email bodies, JSON strings, HTTP headers, data URIs. It converts arbitrary bytes into 64 safe characters, at a cost of about 33% extra size.

Percent-encoding exists because URLs reserve characters such as ?, & and # for structure. See the URL encoder.

Encryption: reversible with a key

Encryption transforms plaintext into ciphertext using a key. Without the key the ciphertext is indistinguishable from random data; with it, the original is recovered exactly.

Symmetric encryption

One key encrypts and decrypts. Fast enough to encrypt terabytes. The problem is getting the key to the other party safely.

• AES-256-GCM — the standard choice. GCM is an authenticated mode, meaning it detects tampering as well as providing confidentiality.
• ChaCha20-Poly1305 — faster than AES on hardware without AES instructions, common on mobile.
• Avoid ECB mode — it encrypts identical blocks identically, which famously leaves the outline of an image visible after “encryption”.

Asymmetric encryption

A public key encrypts and a mathematically related private key decrypts. This solves key distribution: publish the public key freely.

• RSA-2048 or better — widely deployed, slow, large keys.
• ECDH / Ed25519 — elliptic curve, far smaller keys for equivalent strength. A 256-bit ECC key is roughly as strong as a 3,072-bit RSA key.

In practice both are combined. TLS uses asymmetric cryptography to agree a symmetric session key, then encrypts the actual traffic symmetrically because it is orders of magnitude faster.

Hashing: one-way by design

A cryptographic hash function maps input of any length to a fixed-length digest. The mapping is deterministic and irreversible.

Four properties define a usable hash function:

1. Deterministic. The same input always gives the same output.
2. Pre-image resistant. Given a digest, finding an input that produces it is computationally infeasible.
3. Collision resistant. Finding two different inputs with the same digest is infeasible.
4. Avalanche effect. Changing one input bit changes about half the output bits.

SHA-256('hello') = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256('hellp') = 6d1b4b8ba1d4e0d6a1e4bb64d95e19f0a4bd0d13b3c39f0bcac1a0e5ff5c30cd

One letter changed. Nothing about the outputs is similar.

Which algorithm

Generate and compare digests in the hash generator.

Why passwords need a different kind of hash

This is where the distinction matters most, and where the most damaging mistakes happen.

SHA-256 is designed to be fast — that is a feature for verifying file integrity and a catastrophe for passwords. A consumer GPU computes billions of SHA-256 hashes per second, so a stolen database of SHA-256 password hashes is cracked in hours.

Password hashing functions are deliberately slow and memory-hungry:

• Argon2id — winner of the 2015 Password Hashing Competition and the current recommendation. Tunable in time, memory and parallelism.
• scrypt — memory-hard, which specifically frustrates GPU and ASIC attacks.
• bcrypt — older but still sound, with a configurable cost factor. Note its 72-byte input limit.
• PBKDF2 — acceptable where FIPS compliance is required, but the weakest of the four against GPU attacks.

Two further requirements:

Salt. A unique random value per password, stored alongside the hash. Without it, identical passwords produce identical hashes and a single precomputed rainbow table cracks every account at once. All four functions above generate and embed a salt automatically.

Pepper (optional). A secret value stored outside the database — in an environment variable or HSM — and mixed into every hash. If the database alone leaks, the hashes are useless without it.

// Never do this
hash = sha256(password)                  // fast, no salt
hash = md5(password + 'mysecretsalt')    // broken hash, shared salt

// Do this
hash = argon2id(password, randomSalt, memory=64MB, time=3, parallelism=4)

More detail in the password security guide.

HMAC and digital signatures

A plain hash proves data has not changed accidentally. It proves nothing about who produced it — anyone can recompute a hash.

HMAC adds a shared secret to the hash, so only parties holding the key can produce or verify the tag. It is how webhook payloads are authenticated: Stripe, GitHub and Slack all sign requests with HMAC-SHA256 so you can confirm the request genuinely came from them.

signature = HMAC-SHA256(key: webhook_secret, message: raw_body)
// Compare with a constant-time function, never ===

Use a constant-time comparison. A normal string comparison returns early on the first differing byte, and that timing difference is enough to recover a signature byte by byte.

Digital signatures go further using asymmetric keys: the holder of the private key signs, and anyone with the public key can verify. That gives non-repudiation, which HMAC cannot, because with HMAC both parties hold the same secret. This is what signs software releases, TLS certificates and JWTs using RS256 or ES256.

Choosing the right tool

Frequently Asked Questions