MD5, SHA-1, and SHA-256 Explained: Which Hash to Actually Use

A hash function takes any input and squeezes it into a fixed-length fingerprint. Paste a single word or a 4 GB ISO, and you still get the same compact string out. The catch is that not every hash is meant for the same job, and three of the most common ones — MD5, SHA-1, SHA-256 — sit at very different points on the safe-to-use scale. I once shipped a "fast" dedup pipeline keyed on MD5 and only later realized I'd been one careless code review away from someone reusing that same MD5 path to "verify" file authenticity. The fix was free; the lesson stuck.

This guide sorts out what each algorithm is for, why two of them should never guard anything that matters, and why a hash is not encryption no matter how scrambled it looks. You can follow along by pasting your own text into the MD5 / SHA Hash Generator, which computes all five digests at once, entirely in your browser.

What MD5, SHA-1, and SHA-256 Actually Output

The number in each name is the digest length in bits. MD5 produces 128 bits, written as 32 hex characters. SHA-1 produces 160 bits (40 hex). SHA-256 — part of the SHA-2 family — produces exactly 256 bits, or 64 hex characters. More bits means a larger space of possible outputs, which makes accidental and deliberate collisions far harder.

Here is the same three-byte input run through each:

input:   abc
MD5:     900150983cd24fb0d6963f7d28e17f72
SHA-1:   a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Notice that flipping a single character of the input would scramble the entire output — there is no partial resemblance between the hash of abc and the hash of abd. That avalanche behavior is exactly what makes hashes useful as fingerprints.

Why MD5 and SHA-1 Are Broken for Security

A secure hash needs to be collision-resistant: nobody should be able to find two different inputs that produce the same digest. MD5 failed this test decades ago. Practical MD5 collisions have been demonstrated since 2004, and by 2008 researchers used a chosen-prefix MD5 collision to forge a rogue certificate authority certificate that browsers trusted. SHA-1 fell next — Google's 2017 "SHAttered" attack produced two distinct PDF files with the same SHA-1 digest, and the cost of such an attack has only dropped since.

"Broken" does not mean MD5 stops producing output — it means an attacker can engineer collisions on purpose. So MD5 and SHA-1 are still fine for non-adversarial jobs: deduplicating user-submitted snippets, generating a quick cache key, sanity-checking that a non-malicious file transfer didn't truncate. They are not fine for anything an attacker would want to subvert: signatures, certificate fingerprints, integrity checks against tampering, or password storage. For those, reach for SHA-256 or SHA-512.

And never use any raw hash — even SHA-256 — to store passwords. Unsalted hashes fall to rainbow tables in seconds. Password storage needs a deliberately slow, salted function like bcrypt or Argon2.

Hashing Is Not Encryption

This trips up almost everyone at first. Encryption is reversible: with the right key, ciphertext becomes the original plaintext again. Hashing is a one-way street. There is no key, and there is no "unhash" operation that recovers the input from the digest. If a site claims it can email you your original password, it isn't hashing anything — it's storing your password in a recoverable form, which is a red flag.

Because hashing is one-way and deterministic, it answers a different question than encryption does. Encryption asks, "can I keep this secret and get it back later?" Hashing asks, "is this exact thing identical to that exact thing?" When you need keyed integrity — proving a message came from someone holding a shared secret — you combine a hash with a key using HMAC. If that's your goal, the HMAC generator is the right tool rather than a bare digest.

Verifying File Integrity the Right Way

The most common everyday use of hashing is confirming a download arrived intact. Say you pull an Ubuntu ISO from a mirror. The official release page publishes a SHA-256. You run:

shasum -a 256 ubuntu.iso

The 64-hex string it prints must match the published one character-for-character. One mismatched character anywhere means the file is corrupted or tampered with — re-download, don't "just try it." This is where the extra bits of SHA-256 earn their keep: even a motivated attacker can't quietly swap the file for a malicious one that still hashes to the same value.

A frequent gotcha: your digest doesn't match because of an invisible trailing newline. echo "abc" | md5sum actually hashes abc\n (four bytes), not abc (three bytes), so the result differs. Use printf '%s' abc | md5sum or echo -n to be byte-exact. The hash generator on Toolora hashes precisely the bytes you paste, UTF-8 encoded with no added newline — so pasting abc gives the canonical 900150983cd24fb0d6963f7d28e17f72 that matches the printf command.

A Quick Decision Guide

Verifying a download or pinning a certificate fingerprint: SHA-256 (or SHA-512 for larger margins).
Non-security dedup, cache keys, quick fingerprints: MD5 is acceptable, because no attacker is trying to fool you.
Storing passwords: none of the above — use bcrypt or Argon2.
Proving a message came from a shared-secret holder: HMAC, not a plain hash.

When in doubt, default to SHA-256. It's the SHA-2 member with the best size/speed/security tradeoff and the reason it underpins Bitcoin, TLS certificate fingerprints, and git object IDs since 2018.

You can compute and compare all of these side by side in the MD5 / SHA Hash Generator — paste text, read MD5 through SHA-512 instantly, and nothing ever leaves your browser tab.

Made by Toolora · Updated 2026-06-13