Hashing vs Encryption vs Encoding: Know the Difference

Encoding, encryption, and hashing are three of the most frequently confused concepts in software. They all transform data into a different-looking form, but they exist for completely different reasons and provide completely different guarantees. Mixing them up leads to real security failures — like storing passwords with Base64 and believing they are protected.

Encoding: Format, Not Secrecy

Encoding transforms data into a different representation so it can be safely stored or transmitted over a channel with restrictions. Base64, URL encoding, and HTML entity encoding are all encodings. The defining property is that encoding is fully reversible by anyone, with no key and no secret. Base64 is not security; it is a way to fit binary data through a text-only pipe. If you can read the encoded string, you can decode it instantly.

Encryption: Reversible With a Key

Encryption transforms readable plaintext into ciphertext that is unreadable without a secret key. Crucially, it is reversible — but only by someone who holds the correct key. This makes encryption the right tool for confidentiality: protecting data at rest (disk encryption), in transit (TLS), or in a database (encrypted columns). There are two families: symmetric encryption (the same key encrypts and decrypts, e.g. AES) and asymmetric encryption (a public key encrypts, a private key decrypts, e.g. RSA).

Because encryption is reversible, the security of encrypted data rests entirely on key management. Lose control of the key and you lose the protection; lose the key entirely and you lose the data.

Hashing: One-Way Fingerprints

A cryptographic hash function maps input of any size to a fixed-size output (a digest) and is designed to be irreversible: there is no key and no decrypt operation. SHA-256 always produces 256 bits regardless of input length. Good hash functions have three properties: the same input always yields the same output (deterministic), a tiny change in input drastically changes the output (avalanche effect), and it is computationally infeasible to find two inputs with the same output (collision resistance) or to reverse a digest back to its input (preimage resistance).

Hashing is for verification and integrity, not confidentiality. Use it to check that a downloaded file was not corrupted, to deduplicate data, to build hash tables, and — with the right approach — to store passwords.

Passwords: A Special Case

Passwords should be hashed, never encrypted, so that a database breach does not expose them. But plain SHA-256 is the wrong tool: it is fast, which lets attackers try billions of guesses per second. Password hashing requires slow, salted, memory-hard algorithms such as bcrypt, scrypt, or Argon2. The salt — a unique random value per password — ensures two users with the same password get different hashes and defeats precomputed rainbow tables.

HMAC: Hashing Plus a Key

HMAC (Hash-based Message Authentication Code) combines a hash function with a secret key to prove both the integrity and the authenticity of a message. Unlike a plain hash, which anyone can recompute, an HMAC can only be produced or verified by someone holding the key. It is the standard mechanism behind signed API requests, webhook verification, and JWT signatures.

• Need to fit data through a text channel? Encoding (Base64, URL encoding).
• Need to keep data secret but recover it later? Encryption (AES, RSA).
• Need to verify integrity or store passwords? Hashing (SHA-256 for integrity; bcrypt/Argon2 for passwords).
• Need to prove a message came from a trusted party? HMAC.