MD5 vs SHA-256: Which Hash Function Should You Use?

You download a 4 GB installer and the site prints a line of hex underneath it. Or you inherit a database where the password column holds 32-character strings. Or a review comment asks why you used MD5 “for anything”.

All three come back to the same questions: what a hash function actually does, which ones are still safe, and what “safe” even means in context. The short version is that MD5 has a legitimate life left in it — just not the one most people give it.

What a hash function does

A cryptographic hash function takes input of any size and produces a fixed-length digest — a fingerprint of the data. Four properties matter:

• Fixed length. A one-line email and a 4 GB video both produce a 64-character SHA-256 digest. The output size never depends on the input size.
• Deterministic. The same input always yields the same digest. Every time, on every machine.
• One-way. Given a digest, there is no practical way to work backwards to the input.
• Avalanche effect. Change one bit of input and roughly half the output bits flip. Similar inputs do not produce similar digests.

That last one is easy to see. Here is hello and Hello under SHA-256 — a single case change:

hello  → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Hello  → 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

Nothing in common. That is exactly the point: a digest reveals nothing about how close you were.

What hashing is not

Three misconceptions cause most of the trouble.

Hashing is not encryption. Encryption is designed to be undone with a key; hashing is designed never to be undone at all. If someone says a password was “encrypted in the database”, ask a follow-up question.

Hashing is not reversible. No key reverses SHA-256. When a “hash cracking” site returns password123 for a digest, it did not reverse anything — it looked the digest up in a table of pre-computed common inputs, or brute-forced guesses until one matched.

Hashing is not compression. You cannot recover a 4 GB file from 64 characters; the information is destroyed, not squeezed. Moving binary data through a text channel intact is Base64’s job, and that makes data larger, not smaller.

The state of MD5 and SHA-1

Both are considered cryptographically broken, and the specific way they are broken is worth understanding.

The attack that landed is a collision attack: finding two different inputs that produce the same digest. For MD5, collisions have been producible cheaply on ordinary hardware for many years. SHA-1 held out longer, but a practical collision was publicly demonstrated in 2017 with two different PDF files sharing one SHA-1 digest, and the cost of the attack has only fallen since.

Why that is devastating: if I can craft two files with the same digest, I can get you to sign, approve, or whitelist the harmless one — and then swap in the malicious one, which still passes every check. Any system where a hash stands in for “this is the document you approved” is broken by collisions.

A nuance that gets skipped: MD5 is broken for collision resistance, but preimage attacks — starting from a digest and finding an input that produces it — are still not practical. That is why MD5 has not vanished entirely.

Where MD5 is still fine

MD5 survives legitimately as a non-security checksum, where the only adversary is accident rather than malice: detecting a corrupted download or a flaky disk copy, generating cache keys and content fingerprints, finding duplicate files in a photo library, or answering “did this change?” between two copies of data.

In all of those, nobody is trying to trick you — you are guarding against bit rot and network errors, and MD5 does that fine while being fast. (For pure speed with no security pretence at all, non-cryptographic hashes like xxHash are faster still.)

The rule: the moment an attacker benefits from two inputs matching, MD5 and SHA-1 are out.

SHA-256 as the sensible default

SHA-256 belongs to the SHA-2 family and is the pragmatic default for anything security-adjacent today. It has no known practical collision attacks, it is implemented everywhere, and it is fast enough that cost is rarely a factor.

The family differs mainly in digest length:

Algorithm	Digest length	Hex characters
MD5	128 bits	32
SHA-1	160 bits	40
SHA-256	256 bits	64
SHA-512	512 bits	128

SHA-512 is not “more secure enough to matter” for most applications, though it can be faster than SHA-256 on 64-bit hardware. SHA-3 also exists, built on a completely different internal design — it is a hedge against a future break in SHA-2, not a replacement for it.

If you only remember one line: use SHA-256 unless you have a specific reason not to.

Passwords are a different problem

This is the most important section, because it is where good instincts lead people wrong.

Everything above praises hash functions for being fast. For passwords, speed is the vulnerability. If your database leaks and passwords are stored as bare SHA-256 digests, an attacker with a consumer GPU can test enormous numbers of candidates per second against every row at once. Fast hashing means fast cracking.

Two things fix this:

A salt — a unique random value stored alongside each password and mixed into the hash. Salts mean identical passwords produce different digests, so an attacker cannot spot repeated passwords across accounts or use a pre-computed rainbow table. Every user needs their own.

A deliberately slow algorithm — one designed to take a tunable amount of work per guess. Use Argon2 (Argon2id is the modern recommendation), bcrypt, or scrypt. These handle salting for you and let you dial the cost up as hardware gets faster. PBKDF2 remains acceptable where a standards requirement demands it.

Wrong:  sha256(password)
Wrong:  md5(password + "mysecretsalt")
Right:  argon2id(password)   // or bcrypt / scrypt

Do not invent your own scheme by chaining hashes together. Use the library your language already ships.

And since strong passwords are the other half of this: a long random string from a Password Generator resists cracking far better than a clever human-chosen one, regardless of the hashing behind it.

Where hashes earn their keep

• File integrity. Publish a SHA-256 digest next to a download so users can confirm the bytes arrived intact.
• Deduplication. Hash file contents and compare digests — far cheaper than comparing files byte by byte.
• Content addressing. Git identifies every commit and blob by the hash of its contents, which is how it detects corruption.
• HTTP ETags. A hash of a response body lets a browser ask “has this changed?” and skip the download if not.
• Digital signatures. Signing algorithms sign a digest, not the whole document — which is precisely why collision resistance matters so much.

Generating and comparing hashes

Every platform has this built in:

# macOS / Linux
shasum -a 256 installer.dmg
md5sum archive.zip

# Windows PowerShell
Get-FileHash installer.exe -Algorithm SHA256

For a quick digest of a string rather than a file, the Hash Generator produces MD5, SHA-1, SHA-256, and SHA-512 side by side, entirely in your browser — nothing you paste is uploaded.

Two notes on comparing. Hex digests are case-insensitive, so normalise before comparing or you will chase a phantom mismatch. And when comparing a hash of anything secret in code, use your language’s constant-time comparison function — a naive == can leak information through how long it takes to fail.

Quick answers

Is MD5 completely useless now? No — it is fine as a checksum against accidental corruption. It is unusable anywhere an attacker could benefit from forging a match.

Can a SHA-256 hash be reversed? No. Cracking sites guess inputs and compare digests; they do not reverse anything.

Is SHA-512 twice as secure as SHA-256? Not meaningfully. Both are far beyond brute force. Pick SHA-256 unless something specific calls for SHA-512.

Can two files really share a hash? With MD5 and SHA-1, yes, and deliberately. With SHA-256 no practical method is known.

Should I hash passwords with SHA-256? No. Use Argon2, bcrypt, or scrypt with a per-user salt.

The takeaway

A hash is a fixed-length fingerprint: deterministic, one-way, and wildly sensitive to change. MD5 and SHA-1 still compute fingerprints perfectly well, but both can be forged on purpose, so they belong in checksum duty and nowhere near a security decision. SHA-256 is the default that will not get you into trouble.

Passwords sit outside this comparison entirely. They need a slow, salted algorithm built for the job — because everything that makes MD5 and SHA-256 good at hashing files makes them bad at protecting secrets.