How Hashing Works

Feed any text into a hash function and it answers with a fixed-length string of letters and digits — the same length whether you hashed one word or an entire novel. That string is called a digest, and it behaves like a fingerprint: uniquely identifying, impossible to reverse, and impossible to fake. Software downloads, digital signatures, and file deduplication all lean on it. And despite the cipher-like appearance, hashing is not encryption.

What a hash function actually does

A cryptographic hash function takes an input of any size and squeezes it into an output of a fixed size. Three properties make that useful. It is deterministic: the same input always produces the same digest, so anyone can verify a claim by recomputing it. It is one-way: the digest reveals nothing usable about the input, and there is no "unhash" button. And it is collision-resistant: two different inputs effectively never share a digest under a modern algorithm.

The workhorse today is SHA-256, which produces a 256-bit digest — 32 bytes. The SHA-2 family also includes SHA-384 and SHA-512, and the older SHA-1 (160 bits) still shows up in legacy systems. MD5 and SHA-1 are considered broken for security purposes, for reasons the collision section below explains.

Hashing is not encryption

Encryption is built to be reversed: with the right key, ciphertext becomes plaintext again. Hashing is built to be irreversible. There is no key, and the digest is not a scrambled version of the input — it is a fixed-size summary from which the original cannot be recovered, not even by whoever computed it.

That asymmetry is the point. A system that verifies a secret never needs to store the secret itself — only a digest of it — so a database theft does not hand over the originals. One caveat keeps this honest: for anything an attacker might target, a general-purpose hash is not enough on its own, because general hashes are fast. The next sections cover what alone is not enough and why.

The avalanche effect

Change one character of the input and the entire digest changes — completely, unpredictably, with no visible relationship to the previous one:

SHA-256("hello")  = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("Hello")  = 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
SHA-256("hello!") = ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b

One capital letter, one exclamation mark — every bit of the output moves. This is the avalanche effect, and it is what makes digests useful for verification. If a downloaded file's hash matches the hash its publisher published, the file is byte-for-byte identical; if even one bit was corrupted or swapped in transit, the digest will not match and you will know immediately.

Collisions: guaranteed in theory, ignored in practice

A fixed-size output means there are infinitely many possible inputs but only a finite number of possible digests, so collisions must exist in principle. The question is whether anyone can find one. For SHA-256 the output space has 2²⁵⁶ values; by the birthday problem, an attacker would need to compute on the order of 2¹²⁸ hashes before expecting a collision — a workload no computer on Earth comes close to.

Weak algorithms fail not because collisions happen by accident but because researchers found mathematical shortcuts to manufacture them on purpose — that is what "MD5 is broken" means. A manufactured collision lets an attacker dress up a malicious file as a trusted one, which is why MD5 and SHA-1 must never be used where an adversary is involved. The same birthday math that protects UUIDs (see How UUIDs Work) is what makes a wide digest trustworthy.

Salt: hashing the same input differently

A salt is a random value mixed into the input before hashing, so the same input no longer produces the same digest everywhere. Why would you want that? Because identical inputs produce identical digests — and identical digests leak information. If two stored digests are equal, anyone can tell the two inputs were equal, and a table of precomputed digests (a "rainbow table") turns common inputs into simple lookups.

Salting defeats both problems: hashing salt + input with a unique salt per record means two identical inputs hash to different digests, and precomputed tables become useless because every salt changes the answer. The salt does not need to be secret — it needs to be unique, and it is stored alongside the digest it salts. And because fast hashes let an attacker try billions of guesses per second, anything an attacker might target deserves purpose-built, deliberately slow hashing algorithms on top of these ideas — a general hash like SHA-256 is a building block, not the finished wall.

Reading the hex output

Hash tools print digests in hexadecimal: two hex digits per byte, using the symbols 0-9 and a-f. A 32-byte SHA-256 digest becomes 64 hex characters, which is why the output is always an even-length string from that alphabet. Hex is just a compact, unambiguous way to display raw bytes — the digest itself is 32 bytes of binary data, not text.

A quick size guide makes outputs recognizable at a glance: SHA-1 prints 40 characters, SHA-256 prints 64, SHA-384 prints 96, SHA-512 prints 128. If a value labeled "SHA-256" is not 64 hex characters, something else produced it. For how hexadecimal and other positional number systems work under the hood, see Number Base Systems Explained.

Try it yourself

Type anything into the Hash Generator and watch SHA-1, SHA-256, SHA-384, and SHA-512 digest the same input at four different lengths — then change a single letter and watch every digest scramble. To hash a whole list of values at once, the Hash Batch tool processes every line in one pass. To see raw bytes displayed as hex pairs — the same alphabet hashes are printed in — try the Hex Encoder. And for a contrast that makes the one-way property vivid, the Base64 Encoder is fully reversible, which is exactly the property hashing does not have.