MD5 being "broken" does not mean it is useless. It means it fails at one specific job, and that job is not the one most people use it for.
What a hash is for
A hash function turns any input into a fixed-length fingerprint. Change one bit of the input and the output changes completely and unpredictably.
That gives you a cheap way to answer one question: are these two things identical? Compare fingerprints instead of comparing gigabytes.
A hash is one-way by design. You cannot recover the input from the output, which is why hashing is used for password storage — the server stores a fingerprint and checks new attempts against it without ever holding the password.
Which one, and when
| Algorithm | Output | Status |
|---|---|---|
| MD5 | 128-bit | Broken for security; fine for corruption checks |
| SHA-1 | 160-bit | Broken; collisions demonstrated in 2017 |
| SHA-256 | 256-bit | Current default; no practical attacks |
| SHA-512 | 512-bit | Stronger, and faster on 64-bit hardware |
| SHA-3 | variable | Different construction; a hedge against SHA-2 |
| bcrypt / argon2 | variable | For passwords — deliberately slow |
That last row is a different category. General-purpose hashes are fast, which is exactly wrong for passwords — an attacker with a leaked database wants to try billions of guesses. Password hashes are engineered to be slow and memory-hungry. Never store passwords with SHA-256.
What "broken" actually means
MD5 is broken in the sense that collisions can be constructed deliberately: two different inputs producing the same hash, generated in seconds on ordinary hardware.
That matters when an adversary controls the input. A signed certificate, a software update, a legal document — if someone can produce a second file with the same hash, the signature on the first also validates the second.
It does not matter when nobody is attacking you. If you are checking whether a file was corrupted in transit, random corruption producing an MD5 collision is effectively impossible. The failure mode MD5 has is deliberate, not accidental, which is why it survives in checksums and version control.
Verifying a download properly
- Get the expected hash from a different place than the file. This is the step that matters. A hash published on the same page as the download, served by the same server, proves nothing — anyone who replaced the file also replaced the hash.
- Compute the hash of what you downloaded. On Windows:
certutil -hashfile file.iso SHA256. On macOS:shasum -a 256 file.iso. On Linux:sha256sum file.iso. - Compare the whole string, not the first and last few characters. A targeted attack would match those.
- Prefer a signed hash file where the project provides one — a GPG-signed SHASUMS file is meaningfully stronger than a hash on a web page.
The Hash Generator computes MD5, SHA-1, SHA-256 and SHA-512 on your device using the browser's Web Crypto implementation, so a file you are verifying is not uploaded anywhere to be checked.
Where hashes turn up
- Download verification — the case above.
- Deduplication. Identical files have identical hashes, so a storage system can keep one copy. This is also how a photo library spots duplicates.
- Content-addressed URLs. Naming an asset by its hash means a changed file is a changed URL, which is what makes immutable caching safe.
- Git commits. Every object is addressed by its hash, which is what makes the history tamper-evident.
- Digital signatures. A signature is an encrypted hash — the mechanism behind digital signatures explained.
Note that git used SHA-1 historically and has been migrating, precisely because a collision would let someone substitute an object. The same reasoning applies wherever a hash identifies content rather than merely checking it.
A short decision rule
Two questions settle almost every case.
Could an adversary control the input? If yes, SHA-256 or better, and never MD5 or SHA-1.
Is it a password? If yes, none of these — use bcrypt, scrypt or argon2, which are designed to be slow.
If the answer to both is no — you are checking a file transferred correctly, or deduplicating your own photos — MD5 is fast, fine, and half the length to compare by eye.
Frequently asked questions
Is MD5 still safe to use?
For detecting accidental corruption, yes — random corruption producing a collision is effectively impossible. For anything an adversary could manipulate, no: deliberate collisions can be generated in seconds on ordinary hardware.
What does a hash collision mean?
Two different inputs producing the same fingerprint. It matters when someone controls the input — if a second file can be made to match a signed hash, the signature validates both. It does not matter for checking a transfer, where nobody is trying to fool you.
How do I verify a downloaded file?
Compute the hash with certutil on Windows, shasum on macOS, or sha256sum on Linux, and compare the whole string against the published value. Crucially, get the expected hash from a different source than the file — a hash on the same page proves nothing.
Should I use SHA-256 for passwords?
No. General-purpose hashes are fast, which is exactly wrong for passwords — an attacker with a leaked database wants billions of guesses per second. Use bcrypt, scrypt or argon2, which are deliberately slow and memory-hungry.
Is SHA-512 better than SHA-256?
Stronger in principle, and often faster on 64-bit hardware since it works on 64-bit words. SHA-256 has no practical attacks against it, so the choice rarely matters — consistency across your system matters more than the difference.
Why does a hash on the download page not help?
Because anyone who could replace the file could also replace the hash beside it. The check only means something if the expected value comes from somewhere the attacker does not control — a signed SHASUMS file, or a different domain.