Hashing vs encryption vs encoding: what's the difference?
Hashing, encryption, and encoding are three of the most confused concepts in software, and mixing them up leads to real security bugs — like Base64-encoding a password and thinking it is protected. This guide draws a clear line between the three: what each does, whether it can be reversed, whether it needs a key, and when to use it. Try hashing with the Hash Generator and encoding with the Base64 Encoder.
Three different jobs
The three are easy to separate once you ask two questions: is it reversible, and does it need a key?
| Technique | Reversible? | Needs a key? | Purpose |
|---|---|---|---|
| Encoding | Yes, by anyone | No | Represent data in another format |
| Encryption | Yes, with the key | Yes | Keep data confidential |
| Hashing | No | No (HMAC adds one) | Fingerprint data, detect changes, store password verifiers |
Encoding
Encoding transforms data into another representation so it can travel safely, such as Base64 for binary data in text or percent-encoding for values inside a URL. It provides no security whatsoever — anyone can decode it without a key. If a value is Base64 or URL encoded, treat it as fully readable: the Base64 Encoder or URL Encoder turns it straight back into the original.
Encryption
Encryption scrambles data so that only someone with the correct key can read it. It is reversible by design, but only with the key. Use it when you need confidentiality — protecting data in transit or at rest. Symmetric encryption such as AES uses one shared key; asymmetric encryption uses a public key to encrypt and a private key to decrypt.
Confidentiality alone does not stop tampering: without an integrity check, an attacker can often alter the ciphertext and change what it decrypts to. Use an authenticated encryption mode such as AES-GCM or ChaCha20-Poly1305, which refuses to decrypt ciphertext that was modified.
Hashing
A cryptographic hash function turns any input into a fixed-length digest and is one-way: you cannot reverse a digest back to the input. The same input always yields the same digest, and a tiny change to the input produces a completely different one. That makes hashing ideal for fingerprinting data, detecting changes, and storing password verifiers without storing the passwords themselves.
One-way does not mean unguessable. Anyone can hash likely inputs and compare the results, so the digest of a short or common value, such as a password or a phone number, can be found by guessing. Non-cryptographic hashes such as CRC32, or the hash functions behind hash tables, are built for speed rather than these guarantees and must never be used for security.
Keyed hashes: HMAC
A plain hash only proves that data has not changed if the digest itself comes from a trusted source: an attacker who can replace a file can also replace its published hash. HMAC closes that gap by mixing a secret key into the hash, so only someone who holds the key can produce or check a valid tag.
HMAC is how webhook payloads, signed API requests, and JWTs signed with HS256 (HMAC with SHA-256) are verified. It is still not encryption: the message stays readable, and HMAC only proves that it came from a key holder and was not altered.
Why passwords need special hashing
General-purpose hashes like SHA-256 are fast, which is exactly what you do not want for passwords — speed helps an attacker try billions of guesses. Passwords should not be encrypted either, because anyone who obtains the key can decrypt every one of them. Store them with a slow, salted password hashing algorithm instead.
The OWASP Password Storage Cheat Sheet recommends, in order of preference:
- Argon2id — the first choice, with at least 19 MiB of memory, 2 iterations, and 1 degree of parallelism.
- scrypt — when Argon2id is not available.
- bcrypt — for legacy systems, with a work factor of 10 or more. Most implementations only use the first 72 bytes of a password.
- PBKDF2 — when FIPS-140 compliance is required, with 600,000 or more iterations of HMAC-SHA-256.
What a salt does
A salt is a unique random value added to each password before hashing. It ensures that two identical passwords produce different stored hashes and defeats precomputed lookup tables such as rainbow tables. A salt is not a secret: it is stored alongside the hash, and Argon2 and bcrypt libraries typically generate it for you and embed it in the hash string they return.
Choosing a hash algorithm
Match the algorithm to the job: a fast cryptographic hash for integrity checks and fingerprints, HMAC when the check must also prove who produced the data, and a slow password hash for passwords. MD5 and SHA-1 both have practical collision attacks, and NIST is retiring SHA-1 by the end of 2030, so avoid both for anything security-related. The Hash Generator computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 of text or files, and HMACs with a key.
| Algorithm | Status | Use |
|---|---|---|
| MD5 | Broken: collisions are practical | Non-security checksums only |
| SHA-1 | Broken: collisions are practical | Legacy compatibility only |
| SHA-256 | Secure | Integrity checks, fingerprints, digital signatures |
| SHA-512 | Secure | The same uses as SHA-256, with a longer 512-bit digest |
| HMAC-SHA-256 | Secure | Webhooks, signed API requests, HS256 JWTs |
| Argon2id, scrypt, bcrypt, PBKDF2 | Secure when configured as recommended | Password storage (slow and salted) |
Frequently asked questions
Is hashing reversible?
No. A cryptographic hash is one-way — a digest cannot be turned back into the original input. An attacker can only hash likely inputs and compare digests, which is why short or common values such as passwords need a slow, salted password hash.
Is Base64 encoding a form of encryption?
No. Base64 is encoding: anyone can decode it without a key. It provides no confidentiality and must never be used to protect secrets.
Should passwords be encrypted or hashed?
Hashed. Encryption is reversible, so anyone who obtains the key can recover every password. Store passwords with a slow, salted password hash such as Argon2id.
Why can't I use SHA-256 for passwords?
It is too fast, which helps attackers brute-force guesses. Passwords need a slow, salted password hash: Argon2id first, then scrypt, bcrypt for legacy systems, or PBKDF2 when FIPS-140 compliance is required.
What is a salt?
A unique random value added to each password before hashing, so identical passwords produce different stored hashes and precomputed attack tables do not work. A salt is not secret; it is stored alongside the hash.
What is the difference between a hash and an HMAC?
Anyone can compute a plain hash, because it needs no key. An HMAC mixes in a secret key, so only someone who holds the key can create or verify it, which proves the data came from them and was not changed.