MD5 vs SHA-256: Hashing Explained

A hash function takes any input — a word, a file, a gigabyte of video — and produces a fixed-length string called a digest (SHA-256 always outputs 256 bits, or 64 hex characters). Two properties make it useful: it's deterministic (the same input always yields the same digest) and it's one-way (you can't reverse the digest back into the input). Change a single bit of input and the entire digest changes unrecognizably — the 'avalanche effect.'

That makes hashes ideal for fingerprinting: verifying a download wasn't corrupted or tampered with (compare its hash to the published one), detecting duplicate files, or checking whether data changed. A hash is not a password vault or a secret — it's a compact, tamper-evident summary of data.

MD5 produces a 128-bit digest and is fast, but it's cryptographically broken: researchers can deliberately craft two different inputs that produce the same MD5 digest — a 'collision.' That destroys its security value, because an attacker could swap a safe file for a malicious one with a matching hash. MD5 is fine only for non-security uses like a quick checksum against accidental corruption; it must never guard integrity where someone might attack it.

SHA-256 (part of the SHA-2 family) produces a 256-bit digest and has no practical collision attacks, which is why it underpins TLS certificates, software signing, and blockchains. For any security-relevant integrity check, SHA-256 is the sensible default. Note that WebCrypto in browsers deliberately doesn't even ship MD5 or SHA-1 for signing — a quiet nudge toward the algorithms that still hold up.

The most important distinction: hashing is one-way and keyless, while encryption is two-way and keyed. You encrypt data to later decrypt it with a key; you hash data precisely because you never want to get the original back. 'Decrypting a hash' isn't a thing — attackers instead guess inputs and compare hashes, which is why password storage adds a random salt and a deliberately slow algorithm (bcrypt, scrypt, Argon2) rather than a plain fast SHA-256.

For verifying that a message came from someone with a shared secret, you don't use a bare hash — you use HMAC, which mixes a secret key into the hashing so only key-holders can produce a valid tag. That's the difference between 'this data is intact' (a hash) and 'this data is intact and from someone who knows the key' (an HMAC). Pick the tool to the job: checksums for corruption, SHA-256 for integrity, HMAC for authenticity, and a slow salted KDF for passwords.