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.
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 (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 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.
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.
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.)
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.
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.
| 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.
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.
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.
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.
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.
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.
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.
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.
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.