Hashing, Encryption and Encoding Are Three Different Things

Encoding: same information, different alphabet

Encoding exists because channels have restrictions. Email was designed for 7-bit text; JSON strings cannot carry arbitrary bytes; URLs reserve certain characters. An encoding maps data into a form the channel accepts, and anyone who knows which encoding was used — usually obvious from the output — can reverse it with no secret. Base64 turns 3 bytes into 4 characters; hex turns 1 byte into 2; percent-encoding replaces reserved characters with %XX.

Encoding is not obfuscation, though it is often mistaken for it. A password stored as Base64 in a config file is a password in a config file. An API key "hidden" in hex in a mobile app is one xxd away from plain text. If the goal is to prevent a reader from learning the content, encoding is the wrong tool by definition, because it is designed to be undone by everyone.

Encryption: hidden from everyone without the key

Encryption transforms data so that recovering it requires a secret. Symmetric ciphers such as AES use one key for both directions; asymmetric schemes such as RSA and elliptic-curve cryptography use a public key to encrypt and a private key to decrypt. The strength of modern encryption rests entirely on the key: the algorithms are public, scrutinised, and safe to publish. What must be secret is the key, and most real-world failures are key-management failures rather than cipher failures.

Encryption answers exactly one question — can an outsider read this? — and it is worth being precise about what it does not answer. Plain encryption does not tell you whether the ciphertext was altered in transit; an attacker who flips bits in a CBC-mode ciphertext can produce predictable changes in the decrypted output without knowing the key. That is why modern practice uses authenticated encryption (AES-GCM, ChaCha20-Poly1305), which combines encryption with an integrity tag, and why "just encrypt it" is rarely a complete answer.

Hashing: a fingerprint with no way back

A cryptographic hash function takes input of any length and produces a fixed-size digest — 256 bits for SHA-256 — with three properties: the same input always gives the same digest; it is infeasible to find an input that produces a given digest (preimage resistance); and it is infeasible to find two inputs with the same digest (collision resistance). There is no key and no inverse. Infinitely many inputs map to each 256-bit value, so "decrypting" a hash is not a hard problem, it is an ill-posed one.

That makes hashes ideal for integrity and identity. A download page publishes the SHA-256 of a release so you can confirm the file you received is the one they built. Git names every commit and blob by its hash, so the id is the content. Content-addressed storage deduplicates by digest. Certificate transparency logs, blockchain blocks and Merkle trees are all hashes of hashes.

Which hash matters. MD5 has been broken for collisions since 2004 — two different files with the same MD5 can be produced in seconds — and SHA-1 fell to a practical chosen-prefix collision in 2020. Both remain in the wild for legacy checksums, Git's original object ids and old certificates, which is why a tool needs to compute them; but nothing new should choose them. SHA-256 is the default; SHA-512 is faster on 64-bit hardware for large inputs; SHA-3 and BLAKE3 are sound alternatives with different performance profiles.

HMAC: a hash that proves who sent it

A plain hash proves integrity against accidents but not against adversaries: anyone who alters a message can recompute its hash. An HMAC (RFC 2104) folds a secret key into the hash computation, so only a holder of the key can produce a valid tag. That turns a hash into a message authentication code. It is how Stripe, GitHub, Slack and most payment providers sign webhooks: they compute HMAC-SHA256 over the raw request body with your shared secret, send the result in a header, and you recompute it and compare.

Two details cause most HMAC bugs. First, the message must be the exact bytes — a re-serialised JSON body with reordered keys or different whitespace produces a different tag, so verify the raw body before parsing it. Second, the key must be the bytes the provider means: a key given as hex or Base64 must be decoded first, because the string "a1b2c3" and the bytes 0xa1 0xb2 0xc3 are different keys. And compare tags in constant time, so response timing does not leak how many leading bytes matched.

Why a special construction instead of simply hashing key + message? Because every Merkle–Damgård hash — MD5, SHA-1, SHA-256 — is vulnerable to length extension: given H(key + message) and the length of the input, an attacker can compute H(key + message + suffix) for a suffix of their choosing without knowing the key. HMAC's nested structure closes that hole. SHA-3 is immune to length extension by design, but HMAC remains the interoperable standard.

Passwords: none of the above, exactly

Password storage is the case people most often get wrong by applying the right category badly. Passwords must not be encrypted, because whoever holds the decryption key — including an attacker who obtains it with the database — can recover every password. They must be hashed so that verification is possible without recovery. But a fast hash like SHA-256 is too good at its job: a GPU computes billions of SHA-256 values per second, so a leaked table of plain hashes falls to a dictionary of common passwords in hours.

The answer is a password hashing function, designed to be slow and memory-hungry on purpose: Argon2id (the current recommendation), scrypt, or bcrypt. Each is tuned so that one verification costs tens of milliseconds — negligible at login, ruinous at a billion guesses. Each takes a per-user random salt, so two users with the same password get different hashes and a precomputed table is useless. And each should be applied server-side through a maintained library, never assembled from primitives in application code.

One table to settle arguments

Ask what the operation is for

Every one of these techniques is the right answer to a specific question. Can this channel carry these bytes? Encode. Can an outsider read this? Encrypt, and authenticate it. Is this the same file the publisher built? Hash. Did the party I share a secret with send this, unmodified? HMAC. Can I check a password without being able to recover it, even after a breach? Password-hash it. Naming the question first is the whole discipline; picking the technique is then usually obvious, and the mistakes in this article all come from picking a technique before asking.

Frequently asked questions