MD5 vs SHA-256
Short version: SHA-256 unless a legacy system forces MD5. Here's the honest accounting behind that.
| MD5 | SHA-256 | |
|---|---|---|
| introduced | 1992 | 2001 |
| output | 128 bits · 32 hex | 256 bits · 64 hex |
| collisions | practical since 2004 — seconds on a laptop | none known |
| chosen-prefix collisions | yes — used to forge a CA in 2008 | none known |
| ok for security? | no, categorically | yes — current standard |
| ok for corruption checks? | yes | yes |
| relative speed (software) | fast | comparable-to-faster with hardware SHA; slower without |
| publish next to downloads? | stop doing this | yes |
The part that actually matters
MD5's fatal wound is collision resistance: since 2004 anyone can mint two different inputs sharing one MD5, and chosen-prefix techniques let both inputs be meaningful files of the attacker's design. Concretely: a clean installer and a backdoored one can carry the same MD5, so a matching checksum stops meaning "this is the file they published." SHA-256 has no such break — no collision of any kind has ever been produced — which is why it's what checksums are made of in 2026.
Where MD5 legitimately survives
Non-adversarial jobs. Spotting a corrupted transfer, deduplicating your own trusted files, matching the checksum column of a legacy database, checking an old mirror's MD5SUMS (the batch tool reads those). Physics doesn't craft collisions; people do. If no person is in your threat model, MD5 still detects bad luck as well as it ever did — verify against whatever was published via the verify tool.
The speed myth
"MD5 because it's faster" hasn't aged well. Modern CPUs ship SHA-256 instructions that close or reverse the software gap; disks bottleneck file hashing anyway; and if throughput genuinely rules your use case, BLAKE3 beats MD5 while staying secure. Speed is a reason to pick BLAKE3, never a reason to keep MD5.
Bottom line
Verifying someone's download: use whichever they published — an MD5 check still beats no check, just know it only rules out corruption. Publishing or building anything new: SHA-256, no exceptions. Related reading: SHA-1 vs SHA-256 — the same story, one act later.
questions
Is MD5 faster than SHA-256?
In plain software, usually — MD5 does less work per byte. But modern CPUs accelerate SHA-256 in hardware, closing or reversing the gap, and BLAKE3 beats both while staying secure. Speed stopped being a good reason to pick MD5 years ago.
When is MD5 still acceptable?
When no attacker is in the picture: spotting accidental corruption, deduplicating files you already trust, matching a legacy system you can't change. The moment the hash defends against a person rather than bad luck, MD5 is the wrong tool.
Should I publish MD5 checksums for my own downloads?
No — publish SHA-256. Every platform can compute it (sha256sum, shasum -a 256, certutil), and you don't invite the "but MD5 is broken" support thread. The batch tool generates a ready-to-publish SHA256SUMS file.
Do MD5 collisions actually matter for downloads?
Yes, when an attacker can influence the file: collisions let two different files share one MD5, so a tampered version can slip past an MD5 check unnoticed. That attack is documented and cheap — it produced a rogue certificate authority back in 2008.