MD5 vs SHA-256: What's the Difference?
You may have seen values like 5d41402abc4b2a76b9719d911017c592 when checking a file's integrity, in an API response, in an old password database, or next to a software download. These are hash values, and MD5 and SHA-256 are two of the algorithms that produce them. Both still show up constantly in real systems, but they aren't interchangeable — one is considered broken for the things hashes are usually relied on for, and the other is the current standard for the same job. This article explains what each actually is, where the real difference lies, and where each still reasonably shows up today.
What Is a Hash?
A hash function takes an input of any size and produces a fixed-size output, called a hash, digest, or checksum:
hello → [hash function] → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824A cryptographic hash function has a few defining properties:
- Deterministic — the same input always produces the same output.
- Fixed-size output — a one-character input and a ten-gigabyte file both produce a digest of the same length.
- One-way in intended use — you aren't meant to be able to work backward from the digest to the original input.
- Small input changes produce very different outputs — changing a single character anywhere in the input scrambles the entire digest, not just a nearby part of it (this is called the avalanche effect).
On that third point, it's worth being precise: a cryptographic hash is designed to make recovering the original input computationally infeasible, but that doesn't mean the original data can never be discovered through guessing or lookup attacks. If an attacker can guess likely inputs (a short password, a common word) and hash each guess to compare against your digest, they don't need to "reverse" the hash at all. That distinction matters a lot for the password section below.
What Is MD5?
MD5 (Message-Digest Algorithm 5) produces a 128-bit hash, conventionally written as 32 hexadecimal characters:
MD5("hello") = 5d41402abc4b2a76b9719d911017c592MD5 was designed in the early 1990s and became extremely widely used for checksums and, at the time, for security purposes. It's no longer considered suitable for anything that depends on collision resistance — the next few sections explain exactly what that means and why.
What Is SHA-256?
SHA-256 is part of the SHA-2 family of hash functions and produces a 256-bit hash, written as 64 hexadecimal characters:
SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824It's widely used today for file integrity checks, as a component inside digital signature schemes, in certificate systems, for verifying software downloads, in blockchain systems, and in content-addressed systems (where a file is referred to by its hash). That list is worth reading carefully: SHA-256 is usually one component of a larger scheme, not the whole mechanism. A digital signature, for instance, combines a hash with a separate signing key — the hash on its own doesn't authenticate anything; it just gives the signing algorithm a fixed-size, tamper-evident stand-in for the actual message.
MD5 vs SHA-256 Comparison
| Feature | MD5 | SHA-256 |
|---|---|---|
| Family | MD5 | SHA-2 |
| Output size | 128-bit | 256-bit |
| Hex length | 32 characters | 64 characters |
| Collision resistance | Broken — practical collisions exist | Currently considered strong for normal cryptographic use |
| Modern security use | Generally unsuitable where collision resistance matters | Widely used |
| Speed | Fast | More computationally intensive than MD5, still fast for normal data |
| Common role today | Legacy checksums, non-adversarial contexts | Integrity checks and cryptographic applications |
That "speed" row deserves a caveat covered in the passwords section: for password storage specifically, a hash being fast is a liability, not a convenience — so "SHA-256 is more computationally intensive than MD5" is not, by itself, a reason to consider it suitable for hashing passwords.
What Is a Collision?
A collision is when two different inputs produce the same hash output:
Input A → [hash] → same output
Input B → [hash] → same outputBecause a hash function maps an unlimited number of possible inputs onto a fixed number of possible outputs, collisions must exist somewhere mathematically — that's unavoidable with any fixed-size output. What matters for security is whether someone can actually find two colliding inputs in a practical amount of time and effort. A hash function is "collision resistant" when doing that is computationally infeasible. When it isn't, the hash function is considered broken for any use that depends on collision resistance.
Why Is MD5 Considered Broken?
Practical collision attacks against MD5 have existed for years. RFC 6151, which documents MD5's security status, notes that a deliberate collision can be found in roughly a minute on ordinary consumer hardware — this is about an attacker constructing two different inputs that hash the same, not about reversing or brute-forcing an existing hash. That capability has been used to demonstrate real-world attacks, including forged X.509 certificates.
What this means in practice: MD5 should not be used anywhere collision resistance is a security requirement, such as digital signatures or certificate validation. That doesn't mean every existing use of an MD5 checksum instantly becomes dangerous — a non-adversarial legacy checksum, where nobody is deliberately trying to construct a colliding file to fool you, is a different situation from a security-sensitive one where an attacker is actively trying to defeat the check. But for anything you're building today, the safer default is a modern algorithm, not MD5.
Is SHA-256 Secure?
SHA-256 remains widely regarded as a secure cryptographic hash function for general cryptographic use when implemented correctly. That last clause matters: algorithm security is not the same thing as system security. SHA-256 being sound doesn't mean every system that uses it is automatically secure — the surrounding implementation, key management, and protocol design all matter just as much. And critically, as the passwords section below explains, SHA-256 being a secure general-purpose hash function does not make it a good choice for hashing passwords specifically — that's a different problem with a different set of requirements.
MD5 vs SHA-256 for File Checksums
Checking that a downloaded file matches its publisher's checksum is one of the most common everyday uses of hashing:
file.zip → [SHA-256] → 64-character checksumYou compute the hash of the file you downloaded and compare it against the hash the publisher listed. If they match, the file's contents are consistent with what the publisher published under that checksum — a useful check against corrupted downloads or accidental tampering in transit.
One nuance worth being explicit about: a checksum match doesn't, by itself, prove the file came from a trustworthy source — it only proves the file matches whatever checksum you compared it against. If both the file and the checksum came from the same untrusted place, a match tells you nothing about the file's legitimacy. The checksum is only meaningful if you obtained it through a channel you actually trust — the vendor's HTTPS site, a signed release page — separate from the download itself.
MD5 vs SHA-256 for Passwords
Neither raw MD5 nor raw SHA-256 should be used to store passwords. This is worth its own section because it's one of the most consequential mistakes in this space.
The reason isn't that these algorithms are "insecure" in the abstract — it's that they're designed to be fast, which is exactly wrong for password storage. OWASP's password storage guidance states plainly that "fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly." If an attacker obtains a database of fast-hashed passwords, they can test billions of guesses per second on modern GPU hardware, checking each against common password lists and pattern-based guessing.
The right tools for password storage are algorithms specifically designed to be slow and resource-intensive, so guessing at scale is expensive rather than cheap:
- Argon2id — the current OWASP-recommended default, winner of the 2015 Password Hashing Competition, designed to resist both GPU-based and side-channel attacks.
- bcrypt — long-established and still reasonable, generally suggested today mainly for legacy systems where Argon2id or scrypt aren't available.
- scrypt — another memory-hard option, a reasonable alternative where Argon2id isn't available.
These algorithms also build in a per-password salt (random data mixed into each password before hashing) so that identical passwords don't produce identical stored hashes, defeating precomputed lookup-table attacks. Modern libraries for Argon2id, bcrypt, and scrypt handle salting internally, so this generally isn't something you implement by hand. If you're storing passwords, use one of these — not MD5, not SHA-256, not SHA-512.
Hashing vs Encryption
| Hashing | Encryption | |
|---|---|---|
| Direction | One-way by design | Reversible with the correct key |
| Output size | Fixed-size digest, regardless of input size | Ciphertext size generally relates to input size |
| Typical use | Integrity checks, password storage (with a dedicated algorithm) | Confidentiality — keeping data secret from anyone without the key |
| Reversal | No "decrypt hash" operation exists | Decrypts back to the original with the right key |
It's worth stating plainly: hashing isn't mathematically impossible to reverse in some absolute sense — as covered above, an attacker can still guess inputs and check them, and a broken algorithm can have practical collision or even preimage weaknesses. What makes hashing "one-way" is that, for a properly designed algorithm, there's no shortcut back to the input besides trying candidates — unlike encryption, where the key is specifically what lets you reverse the operation directly.
Hashing vs Encoding
These get confused constantly, and they're not related operations. Encoding — Base64 is a common example — is a reversible transformation with no key involved: anyone can decode Base64 straight back to the original data, and the output length scales directly with the input. Hashing is one-way by design and always produces the same fixed-length digest regardless of input size. If you can get your original data back from a value without any secret key, you're looking at encoding, not a hash.
How to Generate MD5 or SHA-256 Hashes With Kravoy
Kravoy's Hash Generator computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512 for both text and files, directly in your browser:
- Open the Hash Generator.
- Choose Text and type or paste your input, or choose File Checksum and select a file.
- All supported algorithms are computed and shown at once — MD5, SHA-1, SHA-256, SHA-384, and SHA-512 — so you don't need to pick just one in advance.
- Copy whichever result you need, or compare it directly against a published checksum.
Example: Hashing the Same Text
To make the size difference concrete, here's the same input hashed both ways (both values verified against a standard cryptographic library, not typed from memory):
Input: hello
MD5: 5d41402abc4b2a76b9719d911017c592
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b982432 characters versus 64 — directly reflecting the 128-bit versus 256-bit output size. That's also why SHA-256 is somewhat more expensive to compute: more output bits generally means more internal computation to produce them, though for ordinary text and file sizes, the difference isn't something you'd typically notice.
What Should You Use: MD5 or SHA-256?
There isn't one universal answer, but the situations are fairly distinct:
- For modern cryptographic integrity — file verification, certificates, signatures — SHA-256 (or another current SHA-2/SHA-3 family member) is the appropriate choice in the large majority of situations today.
- For legacy systems, you may still encounter MD5 in existing protocols or older checksums. Encountering it isn't automatically a crisis, but it's not what you'd choose for something new.
- For passwords, use a dedicated password hashing algorithm — Argon2id, bcrypt, or scrypt — rather than either MD5 or raw SHA-256.
- For non-adversarial legacy checksums — where nobody is trying to actively defeat the check — MD5 may still appear for compatibility reasons. That's a different situation from relying on MD5 for security, and the two shouldn't be conflated.
Common Hashing Mistakes
- Using MD5 for password storage. Fast and broken for collision resistance — the wrong properties for this job.
- Using raw SHA-256 for password storage. Secure as a general-purpose hash, still the wrong tool here — it's fast, and password hashing needs to be deliberately slow.
- Confusing hashing with encryption. There's no way to "decrypt" a hash back to its input.
- Assuming a hash match proves authenticity. It only proves the file matches that specific checksum — the checksum itself needs to come from a trusted source.
- Publishing a checksum without a trusted distribution channel. A checksum hosted alongside an untrusted file protects against nothing.
- Confusing Base64 with hashing. Base64 is reversible encoding; a hash is one-way by design.
- Typing or copying hash values incorrectly. A single wrong character makes a checksum comparison meaningless — always verify against the actual output, not from memory.
- Ignoring collision resistance when it matters. Fine for a casual, non-adversarial checksum; not fine anywhere someone might deliberately try to produce a matching fake.
Frequently Asked Questions
Is MD5 still secure?
Not for anything that depends on collision resistance, such as digital signatures or certificate validation — practical collision attacks exist. It may still appear in non-adversarial legacy checksums, which is a different situation from relying on it for security.
Is SHA-256 better than MD5?
For cryptographic integrity purposes, yes — SHA-256 doesn't share MD5's known collision weaknesses and remains considered strong for that use. But "better" isn't the same as "correct for every job": SHA-256 is still the wrong choice for password storage, where a dedicated slow algorithm like Argon2id is what you actually want.
Is SHA-256 encryption?
No. SHA-256 is a hash function — one-way by design, with no key and no way to recover the original input from the output. Encryption is a separate, reversible operation that requires a key.
Can SHA-256 be decrypted?
There's no "decrypt" operation for a hash. Given a SHA-256 output, the only way to find an input that produces it is to guess candidate inputs and hash each one to check — not to reverse the algorithm directly.
Why is MD5 32 characters?
MD5 produces a 128-bit digest, and each hexadecimal character represents 4 bits, so 128 ÷ 4 = 32 characters.
Why is SHA-256 64 characters?
Same logic at a larger size: SHA-256 produces a 256-bit digest, and 256 ÷ 4 = 64 hexadecimal characters.
Should passwords be hashed with SHA-256?
No. Use a dedicated password hashing algorithm — Argon2id, bcrypt, or scrypt — which is deliberately slow and typically handles salting for you. General-purpose hashes like SHA-256 are fast, which makes large-scale password guessing far cheaper for an attacker.
Can I use MD5 for file checksums?
For a casual, non-adversarial integrity check — confirming a file wasn't accidentally corrupted — it still works. Anywhere someone might deliberately try to produce a different file with a matching checksum, use SHA-256 or another modern algorithm instead.
What is the difference between a checksum and a cryptographic hash?
In practice, they overlap a lot — a checksum is any value used to verify data integrity, and a cryptographic hash (like MD5 or SHA-256) is commonly used to produce one. The distinction that matters is collision resistance: a checksum algorithm designed only to catch accidental corruption (like a simple CRC) offers no protection against a deliberate attacker, while a cryptographically secure hash is specifically designed to resist that.