SHA-256 vs SHA-1 vs MD5: which hashes are still safe in 2026

A preimage attack starts with a digest and finds any input that produces it. This is the one people imagine when they hear "broken", and it is not practical against MD5, SHA-1 or anything newer — the best published results are still astronomically far from feasible. If someone hands you a hash, your file is not recoverable from it.

A second-preimage attack is narrower: you are given a specific file and must find a different file with the same digest. This is the property that matters for "did my download get swapped?", and it too holds for MD5 and SHA-1 in any practical sense. An attacker cannot take Ubuntu's ISO and craft a malicious image with the same MD5.

A collision attack is the weakest of the three and the one that fell. Here the attacker controls both files: they craft two documents, from scratch, that happen to share a digest. That sounds academic until you remember that the attacker is often also the author — of a certificate, a contract, a signed binary — and then producing a harmless twin of a malicious file is exactly the attack.

MD5 produces a 128-bit digest — 32 hex characters — and was designed in 1991. In August 2004, Xiaoyun Wang and her collaborators announced a practical collision, and the cost fell off a cliff from there. Today a chosen-prefix MD5 collision, where the attacker gets to pick meaningful content for both halves, runs on a laptop in minutes.

This is not theoretical. The Flame malware discovered in 2012 used a chosen-prefix MD5 collision against a Microsoft Terminal Server Licensing Service certificate to forge a code-signing certificate that Windows accepted, letting it masquerade as a Windows Update package. The signature was valid; the hash it signed described a file nobody at Microsoft had ever made.

So where is MD5 still fine? Anywhere the adversary is entropy rather than a person. Detecting an interrupted download, spotting bit rot in an archive, deduplicating your own photo library, matching files against a vendor's published list when you already trust the vendor and the transport. If an MD5 published in 2009 is all a project ever gave you, checking it is still far better than checking nothing.

SHA-1 produces a 160-bit digest — 40 hex characters. On 23 February 2017, researchers at CWI Amsterdam and Google published SHAttered: two different PDF files with the same SHA-1 hash. The computation took roughly 9.2 quintillion SHA-1 operations, about 6,500 CPU-years and 110 GPU-years, and it was an identical-prefix collision, meaning the two files had to share a large common beginning.

The more dangerous result arrived in January 2020, when Gaëtan Leurent and Thomas Peyrin demonstrated a chosen-prefix collision for SHA-1 — "SHA-1 is a Shambles" — for roughly 45,000 US dollars of rented GPU time. Chosen-prefix is the variant that lets you collide two genuinely different documents, and at that price it is within reach of ordinary criminal budgets, let alone state ones.

The ecosystem had already moved. Browsers stopped trusting SHA-1 certificates in early 2017; Git added collision detection to its SHA-1 implementation in version 2.13 the same year and has been growing a SHA-256 object format since. SHA-1 survives as an identifier in legacy systems and on old release pages, and that is exactly how HashCheckr treats it: available, computed, and labelled legacy.

SHA-2 is a family published by NIST in 2001 — SHA-224, SHA-256, SHA-384 and SHA-512 — built on the Merkle–Damgård construction, the same broad shape as MD5 and SHA-1. That shared lineage is why its 2001 arrival did not feel like enough insurance: if someone found a structural break in the family, SHA-2 might follow. A quarter of a century later no such break exists, and SHA-256 remains the default for release checksums, certificates and signatures.

SHA-3 was NIST's answer to that worry. Keccak won a public competition in 2012 and was standardised as FIPS 202 in 2015, and it is deliberately not a SHA-2 relative: it uses a sponge construction rather than Merkle–Damgård. That difference has a practical side effect — SHA-3 is immune to length-extension attacks, where knowing SHA256(secret ‖ message) lets you compute the hash of a longer message without knowing the secret. SHA-3 is a structural backup, not an upgrade; picking it over SHA-256 buys diversity, not strength.

One detail surprises people: on 64-bit processors SHA-512 is usually faster than SHA-256, because it works on 64-bit words while SHA-256 works on 32-bit ones. SHA-384 is simply SHA-512 truncated to 384 bits with a different initial state, which is why it is the digest you see inside subresource integrity attributes.

BLAKE3, released in January 2020, is the fastest secure hash in common use. It gets there by hashing the input as a Merkle tree, which means it parallelises across cores and SIMD lanes instead of being forced through one sequential chain. On the same machine it is routinely several times quicker than SHA-256, and it produces a 256-bit digest by default — the same 64 hex characters.

Its drawback is social rather than technical: far fewer projects publish b3sum values, so BLAKE3 is mostly useful for hashes you generate and consume yourself — deduplication, build caches, verifying your own backups. If you are choosing an algorithm for a manifest other people will check, SHA-256 is still the one everybody's tooling already speaks.

CRC32 and xxHash64 belong in a separate box entirely. They were never designed to resist an adversary — CRC32 is the error-detecting code inside ZIP archives, PNG chunks and Ethernet frames, and xxHash64 exists to be absurdly fast for hash tables and deduplication. Colliding either one on purpose is trivial. They are excellent at their jobs and must never be asked to do a security one.

Publishing checksums for other people, or verifying a download that matters: SHA-256. It is the default everywhere, hardware-accelerated on modern CPUs, and has no practical weaknesses. SHA-512 if you want a wider margin and your tooling supports it; SHA3-256 if you specifically want a design unrelated to SHA-2.

Hashing terabytes for your own bookkeeping, where speed dominates: BLAKE3. Checking a file against an old page that only offers MD5 or SHA-1: use them, and understand that you are testing for accidents rather than for tampering. Building a hash table or a dedupe index: xxHash64 or CRC32, and never a word about security.

When a project publishes several digests for the same file, check the strongest one it offers rather than the first one in the list. HashCheckr computes as many as you tick in a single pass over the file, so choosing SHA-256 and MD5 together costs no extra reading time — the same chunk is handed to both hashers before it is discarded.