Hashing Explained

Hashing is one of the load-bearing ideas of computing, yet it is routinely confused with encryption and with encoding — three completely different operations that happen to all turn readable data into gibberish. This guide builds the concept from first principles: what a cryptographic hash function actually does, why it is one-way, what the avalanche effect means, and — with a worked example you can reproduce in seconds — why changing a single character rewrites the whole digest. Then it draws the honest lines: hashing is not encryption and not encoding, MD5 and SHA-1 are broken for security while SHA-256 is the default, and a raw fast hash is not a safe way to store passwords.

What a cryptographic hash function is

A cryptographic hash function is a fixed recipe that takes an input of any size — one character, a paragraph, a 4 GB disk image — and produces a short, fixed-length string of bytes called a digest (or just "the hash"). Four properties define a good one:

• Deterministic. The same input always produces exactly the same digest, on every machine and every correct implementation, forever. There is no randomness and no timestamp involved.
• Fixed length. The output size never changes with the input size. SHA-256 always emits 256 bits — 64 hexadecimal characters — whether you hash the empty string or a feature film. The digest is a fingerprint, not a compressed copy.
• One-way (preimage-resistant). Given a digest, there is no feasible way to work backwards to an input that produces it. The only known method is to guess inputs and hash them until one matches, which is hopeless for anything with real entropy.
• Avalanche. Flip a single bit of the input and roughly half the output bits flip, unpredictably, so the new digest looks completely unrelated to the old one.

Together these make a digest behave like a tamper-evident seal: easy to compute in one direction, effectively impossible to reverse, and violently sensitive to the smallest change.

Worked example: the avalanche effect

Take the five lowercase letters hello and hash them with SHA-256, then change just the final o to a p — a one-character edit, one of 40 bits of input touched. Watch what happens to the digest:

The two inputs differ by one letter, but the two 64-character digests share no run of characters and no visible pattern — they are as different from each other as any two random 256-bit numbers. That is the avalanche effect in the flesh. It is exactly why a hash is a trustworthy fingerprint: you cannot look at two digests and tell whether their inputs were almost identical or wildly different, and the tiniest tampering with a file is impossible to hide. Note too that both outputs are the same length; the fixed-length rule holds no matter what goes in. Even the empty string has a well-defined SHA-256, e3b0c442…7852b855.

Hashing is not encryption, and not encoding

This is the single most common — and most consequential — confusion, so it is worth stating flatly. Three operations turn readable data into something that looks scrambled, and they are not interchangeable:

Encoding like Base64 is fully public and reversible by anyone — it has no secret at all; it just rewrites the same bytes in a safer alphabet. Encryption is reversible too, but only if you hold the key; that reversibility is the whole point, because you need your data back. Hashing is the odd one out: it is deliberately not reversible, and it has no key. There is no "decrypt the hash" operation, and any website that claims to reverse one is simply looking the digest up in a precomputed table of common inputs — which works for password123 and never for a strong, high-entropy value.

SHA-256 vs the broken hashes

Not all hash functions are still trustworthy. The security property that matters most here is collision resistance: it must be infeasible to find two different inputs that produce the same digest. When that breaks, an attacker can forge a document that matches a legitimate one's hash.

MD5 has been broken for practical collisions for years, and in 2017 Google's SHATTERED project published two different PDF files that share a single SHA-1 digest — so neither belongs anywhere a determined attacker could try to forge a match, such as digital signatures, TLS certificates or software-update verification. The honest nuance: MD5 and SHA-1 are still perfectly fine as non-security checksums, where nobody is adversarially trying to collide them. Git names its objects with SHA-1, and plenty of caches, ETags and deduplication systems use MD5, because there the only "attacker" is bit-rot and accidental corruption. Reach for SHA-256 (or SHA-384/512) the moment the digest is a security boundary.

What hashing is genuinely for

Given all those "nots," it helps to be concrete about what hashing is for:

• Integrity and checksum verification. A publisher lists the SHA-256 of a download; you hash the file you received and compare. If every character matches, the bytes are identical to what was released — no corruption in transit, nothing injected. One differing character means discard it. This is the everyday job of a hash.
• Deduplication and content addressing. Because the digest is a compact, near-unique fingerprint, systems use it as an identity: store a file under its hash and you can instantly tell whether you already hold identical content, skip re-uploading it, or spot duplicates across a huge store — the mechanism behind Git commits and many backup tools.
• Password storage — but only done right. A server never needs your actual password, only proof you know it, so it stores a hash and compares. The catch: a plain, fast hash like a single SHA-256 is not adequate. Attackers with a leaked table can try billions of fast-hash guesses per second. Safe storage needs a per-user random salt (so identical passwords hash differently and precomputed tables are useless) plus a slow key-derivation function — bcrypt, scrypt or Argon2 — deliberately tuned to take a fraction of a second per guess, turning "billions per second" into a losing game. If you take one rule from this section: never protect passwords with a single raw fast hash.

Putting it together

A cryptographic hash is a deterministic, fixed-length, one-way fingerprint that avalanches on the smallest change. It is not encoding (public and reversible by anyone), not encryption (reversible with a key) — it is a seal that proves data is what it claims to be. Use SHA-256 as your default, treat MD5 and SHA-1 as checksums-only relics, and remember that passwords demand a salted, slow KDF rather than any single fast hash. Get those distinctions straight and hashing stops being cryptic magic and becomes what it really is: a simple, sturdy tool for proving that bytes have not changed.

Open the SHA Hash Generator → to hash text or a file and reproduce the avalanche example above, or browse all Polyatic tools.