Hashing Explained: MD5 vs SHA-256

What a hash function does

A cryptographic hash function has four key properties. It is deterministic — the same input always produces the same output. It is fast to compute in one direction and practically impossible to reverse — you cannot reconstruct the input from the hash. A tiny change in the input produces a wildly different output, a property called the avalanche effect. And collisions — two different inputs producing the same hash — are so rare for a good function that they can be ignored in practice.

These properties make hashes ideal for fingerprints. To check whether a downloaded file is intact, hash it and compare the result with the published value. To store a password safely, hash it with a salt and store the hash; when the user logs in, hash what they typed and compare. The server never needs to know the password itself.

MD5("hello")    -> 5d41402abc4b2a76b9719d911017c592
SHA-256("hello") -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
MD5("hellp")    -> c983190483df167d2a3841463c2a9341  (completely different)

MD5: fast, broken, and still everywhere

MD5 produces a 128-bit hash, written as 32 hex characters. It was designed in 1992 and became the standard checksum of the internet. The problem is that MD5 is broken: researchers can now construct two different files with the same MD5 hash in seconds. That means an attacker can swap a file for a malicious one that still matches the published checksum.

MD5 is still fine for non-security uses, like spotting accidental corruption or deduplicating files, because accidental collisions are still essentially impossible. But it must never be used where an adversary might forge a match — file integrity against tampering, digital signatures, or password storage.

SHA-256: the modern default

SHA-256 produces a 256-bit hash, written as 64 hex characters, and it belongs to the SHA-2 family designed by the NSA and published by NIST. No practical collision attack against SHA-256 is known, and the hash is long enough that brute-force collision search would take longer than the age of the universe with any conceivable hardware. That is why SHA-256 is the default fingerprint for downloads, Git commits, TLS certificates and blockchain blocks.

SHA-256 is slower than MD5, but on modern hardware it still processes hundreds of megabytes per second — more than fast enough for any verification task. When you need a hash and have no specific reason to choose otherwise, SHA-256 is the right answer.

Hashes are not for passwords — use bcrypt

A critical mistake is storing passwords with a fast hash like MD5 or even SHA-256. Fast is the problem: an attacker with a stolen database and a GPU can try billions of SHA-256 guesses per second, and common passwords fall in minutes. Password hashing needs the opposite — a slow, deliberately expensive function that makes each guess cost real time.

That is what bcrypt is for. It is adaptive: a cost factor controls how slow it is, so it stays expensive as hardware improves. It also builds in a random salt per password, so identical passwords produce different hashes and precomputed rainbow tables are useless. The rule is simple: checksums and file fingerprints use SHA-256; passwords use bcrypt (or scrypt, or Argon2).

• File integrity, downloads, Git — use SHA-256.
• Quick non-security checksums — MD5 is acceptable.
• Password storage — use bcrypt, scrypt or Argon2, never MD5 or plain SHA-256.
• Digital signatures — use SHA-256 or SHA-512 with proper signing.

How to use hashes in practice

When you download software, compare the published SHA-256 checksum with a hash of the file you received — if they differ by even one character, do not install it. When you build a system that stores passwords, reach for your framework's bcrypt support instead of writing your own hashing code. And when you need a quick hash of a string while debugging, a hash tool gives you MD5, SHA-1, SHA-256 and more in one place, with HMAC support when you need a keyed hash.

One last caution: a hash proves integrity, not authenticity, on its own. A checksum published on the same compromised page as the download can be replaced along with the file. For real assurance, the checksum should come through a separate trusted channel — or better, the file should be digitally signed.

HMAC: hashing with a key

A plain hash has one weakness: anyone can compute it, so it cannot prove who produced the data. HMAC (Hash-based Message Authentication Code) fixes that by mixing a secret key into the hash. Only someone who holds the key can produce the correct HMAC, so it proves both integrity and authenticity at once.

HMAC is the standard way to sign API requests and verify webhooks. When a payment provider sends your server a notification, it includes an HMAC of the payload computed with a shared secret; your server recomputes the HMAC and compares it. If they match, the message really came from the provider and was not altered in transit. The same idea secures signed URLs: the signature in the URL is an HMAC, and a tampered URL fails verification.