Choosing between MD5 vs SHA-256 comes down to one question: do you need real security, or just a quick fingerprint? MD5 is a 128-bit hash function that is fast but cryptographically broken, researchers have demonstrated practical collision attacks against it since 2004. SHA-256, producing a 256-bit digest, is the current standard for anything security sensitive. This guide compares the two honestly, including the narrow cases where MD5 is still acceptable. Browse the full tools collection for utilities that work with text, data, and conversions every day.
What a hash function does
A cryptographic hash function takes input of any size and produces a fixed size “fingerprint” called a digest. Good hash functions are deterministic (same input, same output), fast to compute, and practically impossible to reverse. You cannot reconstruct the input from the digest. They are also collision resistant: it should be infeasible to find two different inputs that produce the same digest. That last property is exactly where MD5 fails.
MD5: fast, 128-bit, and broken for security
MD5 (Message Digest 5, designed in 1991) produces a 128-bit digest, usually written as 32 hexadecimal characters, like 5d41402abc4b2a76b9719d911017c592. For years it was the default checksum everywhere. Linux ISOs, file downloads, and database fingerprints.
The problem is collisions. Since 2004, cryptographers have shown how to construct two different files with the same MD5 hash, and the attacks have only gotten cheaper. That means an attacker can craft a malicious file that matches the MD5 of a legitimate one. For any scenario where an adversary might tamper with data, software distribution, digital signatures, certificates. MD5 is unsafe and must not be used.
SHA-256: the 256-bit current standard
SHA-256 belongs to the SHA-2 family published by NIST in 2001. It produces a 256-bit digest (64 hex characters), giving it a vastly larger output space than MD5, 2256 possible values versus 2128. No practical collision attack against SHA-256 is known, and it remains the recommended choice for file integrity verification, HMAC message authentication, digital signatures, and systems like Git that depend on content addressing.
SHA-256 is somewhat slower than MD5, but on modern hardware the difference is negligible for nearly all real workloads, and hardware acceleration for SHA-256 is now common in CPUs.
Side by side comparison
- Digest size: MD5 → 128 bits (32 hex chars); SHA-256 → 256 bits (64 hex chars).
- Collision resistance: MD5 → broken (practical collisions since 2004); SHA-256 → no practical attack known.
- Speed: MD5 is faster in software, but the gap rarely matters; SHA-256 has CPU hardware support on modern chips.
- Security status: MD5 → unsuitable for any adversarial use; SHA-256 → the conservative default.
- Typical uses today: MD5 → legacy checksums and non security fingerprints; SHA-256 → downloads verification, TLS certificates, blockchains, password adjacent systems (with proper constructions like HMAC or key stretching).
When MD5 is still acceptable
MD5 is not “useless”, it is only unfit where an attacker is in the picture. Reasonable non security uses include checksums for detecting accidental corruption (a flipped bit during a transfer you control), partitioning data in hash tables, and identifying duplicate files in your own archive. Even here, though, there is little reason to choose MD5 for anything new: SHA-256 costs almost nothing extra and removes the entire class of worry.
Never use MD5 (or plain SHA-256) for passwords
Passwords deserve special mention. Neither MD5 nor raw SHA-256 is appropriate for storing passwords, because both are fast and fast is exactly what you do not want when an attacker is guessing billions of candidates per second. Password storage requires deliberately slow, salted, memory hard functions such as bcrypt, scrypt, or Argon2. If you inherited a system storing MD5 password hashes, migrating to a proper password hash is a genuine security priority. (And note the related misconception: Base64 is not encryption either, see Is Base64 Encryption? for why encoding is not protection.)
The practical rule
For anything new, use SHA-256 (or a stronger SHA-2/SHA-3 variant) by default. Keep MD5 only where legacy systems demand it and no adversary can influence the hashed data. When someone publishes both an MD5 and a SHA-256 checksum for a download, verify the SHA-256 one.
Worked example: verifying a downloaded file, step by step
You download an installer and the publisher’s site lists a SHA-256 checksum next to it. Here is what verification actually looks like. First, compute the digest of the file you received, on Linux the command is sha256sum, on macOS shasum -a 256, and on Windows PowerShell offers Get-FileHash. Second, compare the result with the published value character by character; most people sensibly compare the first eight and last eight characters first, then the full string if those match. If every character agrees, the file on your disk is bit for bit the file the publisher released. If even one character differs, stop: the download is corrupt or tampered with, and re downloading from the official source is the only safe move.
To see why a single changed character matters, consider the two tiny inputs hello and Hello identical except for one capital letter. Their MD5 digests are 5d41402abc4b2a76b9719d911017c592 and 8b1a9953c4611296a827abf8c47804d7: not one digit in common, practically speaking. Their SHA-256 digests, 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 and 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969, are just as unrelated. This avalanche effect is what makes verification trustworthy: there is no such thing as a hash that “almost matches.” Close is a fail.
MD5 vs SHA-256 at a glance
| Property | MD5 | SHA-256 |
|---|---|---|
| Published | 1991 | 2001 (SHA-2 family) |
| Digest size | 128 bits | 256 bits |
| Digest as hex | 32 characters | 64 characters |
| Collision attacks | Practical since 2004 | None practical known |
| Storage for one million digests | About 16 MB | About 32 MB |
| Sensible use today | Legacy checksums, spotting accidental corruption | Download verification, signatures, integrity checks |
The storage row explains the one honest argument for MD5’s survival: at enormous scale its digests take half the space. But 16 extra megabytes per million records is a trivial price for collision resistance, which is why new systems keep choosing SHA-256 anyway.
Common mistakes to avoid
- Verifying a download with MD5 when SHA-256 is offered. A matching MD5 proves little against an attacker who can engineer collisions. When a publisher lists both, the SHA-256 value is the one doing real work.
- Trusting a checksum served next to the file. If you download both the file and its hash from the same compromised page, the pair will match beautifully and mean nothing. Get the hash from the project’s official site over HTTPS, ideally one you navigated to independently.
- Storing passwords with either hash. Both are fast, unsalted digests, exactly what a guessing attack wants. Password storage needs bcrypt, scrypt or Argon2, and users need unique passwords in the first place, which a password generator makes painless.
- Comparing only the first few characters. Eyeballing a prefix is a fine first pass, but a real verification compares the complete digest. Paste both strings into a tool or use your shell’s comparison rather than squinting at 64 hex characters.
- Treating a hash as encryption. A digest hides nothing recoverable and protects nothing by itself; short inputs (a name, a yes/no answer) can simply be guessed and re hashed. If data needs secrecy, encrypt it, a fingerprint is not a lock.
If you maintain a system that still stores MD5 password hashes, treat the migration as two fixes at once: re hash with a proper password function as each user next signs in, and encourage everyone to replace reused passwords at the same time, a strong password generator turns that chore into a copy paste. The hash upgrade protects the database; the password upgrade protects the user everywhere else they reused the old one.
How MD5 fell: a short history
MD5 was not careless work, when it appeared in 1991 it was a respected design, and for a decade it did its job well. The warnings came gradually. In the mid-1990s researchers found weaknesses in parts of its internal compression function, which did not break MD5 outright but suggested the safety margin was thinner than hoped. The decisive blow landed in 2004, when a team led by Xiaoyun Wang demonstrated full collisions: two different inputs producing the same MD5 digest, generated on ordinary hardware. From that point MD5’s story was the usual one in cryptography, the attacks only improved, growing cheaper and more flexible, until researchers could construct colliding files with meaningful content of their choosing, including, in one famous demonstration, a fraudulent security certificate that browsers would have trusted.
The lesson generalises beyond one algorithm. Hash functions do not usually collapse overnight; they erode, over years, while systems built on them quietly accumulate. SHA-1 followed the same trajectory a decade later. That is exactly why the conservative advice in this guide is to build on SHA-256 now and to treat any MD5 you still meet as legacy plumbing: fine where nobody gains from attacking it, and on borrowed time everywhere else.
Where you will still meet MD5
Declaring MD5 unsuitable for security does not make it vanish, and you will keep meeting it in places where it is doing an honest non security job. File managers and sync tools use fast hashes to spot duplicate files and to notice which files changed between runs, there, a collision would have to occur by accident, and the consequence would be a missed update, not a forged certificate. Caches and content stores use digests as convenient names for blobs of data. Legacy download pages still print MD5 values because they always have, and plenty of internal systems pass MD5 fingerprints between components that all sit inside one trust boundary.
The risks in these settings are real but graded. The danger line is crossed when the hashed content can be influenced by someone who benefits from a collision, or when the digest is presented to you as proof of authenticity. If you maintain a system in the grey zone, migration is usually straightforward: because a hash cannot be converted, you recompute SHA-256 digests from the original data wherever you still hold it, run both values side by side during the changeover, and retire MD5 once nothing reads it any more. What you cannot do is wait for a forcing incident, systems migrated calmly, on a schedule, are the ones that never make the news.
Frequently asked questions
Is MD5 completely broken?
For collision resistance yes, practically broken since 2004, and the attacks keep improving. It still detects random corruption fine, but it must not be used anywhere an attacker could craft colliding inputs, such as signatures or software distribution.
Which is faster, MD5 or SHA-256?
MD5 is faster in pure software, but the difference is small on modern hardware, and many CPUs accelerate SHA-256 directly. Speed is not a reason to pick MD5 for new work.
Is SHA-256 unbreakable?
No hash function can be proven unbreakable, but SHA-256 has withstood over two decades of analysis with no practical collision or preimage attack. It is the conservative, widely recommended choice today.
Can I convert an MD5 hash to SHA-256?
No, hashes are one way. You cannot recover the original data from an MD5 digest, so you cannot re hash it as SHA-256. You need the original input to compute a new SHA-256 digest.
Which hash should I use to verify a downloaded file?
SHA-256. Download the checksum from the official source (ideally over HTTPS), compute the SHA-256 of your file, and compare. If they match, the file is intact and authentic as published.