MD5, SHA-1, SHA-256, SHA-512: what to use in 2026
There are two questions developers ask about hash algorithms, and they usually get conflated: "Is this algorithm safe?" and "Should I use this to hash passwords?" The answer to the first depends on the algorithm. The answer to the second is almost always no, use a password-hashing function instead — regardless of the algorithm. This guide walks through the first question for each of the hashes DevDecoder supports, and then explains why the second question deserves its own answer.
What a cryptographic hash is supposed to do
A hash function maps arbitrary input to a fixed-size output. For a cryptographic hash, three additional properties matter:
- Preimage resistance. Given a hash, it's computationally infeasible to find any input that produces it.
- Second-preimage resistance. Given one input, it's infeasible to find a different input with the same hash.
- Collision resistance. It's infeasible to find any two distinct inputs with the same hash.
When an algorithm is called "broken," usually one or more of those properties has been defeated in practice — not in theory. Theoretical weaknesses become practical when compute catches up, and both MD5 and SHA-1 have crossed that line.
MD5
Output: 128 bits (32 hex characters). Status: collision-broken since 2004; practical attacks demonstrated many times. Do not use for any security purpose.
MD5 was designed in 1991. Collisions were found in 2004, and by 2008 researchers had produced two X.509 certificates with the same MD5 hash — meaning a forged certificate could be made to look legitimate. Today anyone with a laptop can generate MD5 collisions in seconds.
Still, MD5 is not entirely dead. Non-adversarial uses are fine:
- Detecting accidental corruption in files you produced yourself (e.g. a build pipeline that hashes its own outputs for a sanity check).
- Sharding data across buckets where you don't care about adversarial input.
- Comparing identical cached values when a collision just means a cache miss, not a security breach.
Don't use MD5 for signatures, integrity verification against a third party, content addressing, or anything where an attacker controls the input.
SHA-1
Output: 160 bits (40 hex characters). Status: collision attacks are practical. Don't use for new work.
SHA-1 was the successor to MD5 and was widely used until collisions started becoming practical in the mid-2010s. The 2017 "SHAttered" attack from Google and CWI produced two distinct PDFs with the same SHA-1 hash. By 2020 the cost had fallen to under $50,000 of cloud compute for a chosen-prefix collision — the kind that lets you forge signatures and certificates.
Legitimate use cases remaining:
- Git commit IDs. Git still uses SHA-1 for commit hashing, but in a context where collisions are a correctness problem, not a security one. The Git project has an ongoing migration to SHA-256.
- Legacy interop. Old TLS certificates, older Samba, older Git hosting. Upgrade where you can.
- HMAC-SHA-1. Interestingly, HMAC is more resilient to the underlying hash's weaknesses than straight hashing — the OTP standard (RFC 6238) still uses HMAC-SHA-1. New systems should use HMAC-SHA-256, but existing HMAC-SHA-1 usage is not immediately broken.
SHA-256 (SHA-2 family)
Output: 256 bits (64 hex characters). Status: secure, widely deployed, the default choice for most use cases in 2026.
SHA-256 is a member of the SHA-2 family (designed by the NSA, standardized by NIST in 2001). It has no known practical attacks. The theoretical gap between best-known attacks and brute force is narrow enough that someone might someday find a meaningful weakness, but no serious cryptographer expects that any time soon.
This is the right default for:
- File integrity checks (
sha256sumon Linux,Get-FileHashon Windows). - Digital signature inputs.
- HMAC for webhook verification (Stripe, GitHub, Slack all use HMAC-SHA-256).
- Content addressing (e.g. Docker image layers, IPFS).
- Blockchain proof-of-work (Bitcoin specifically).
- General-purpose "fingerprint this data" use cases.
SHA-384 and SHA-512
Output: 384 or 512 bits. Status: secure, same family as SHA-256.
SHA-384 and SHA-512 are members of the SHA-2 family with larger outputs. They're built on 64-bit arithmetic, which on modern 64-bit CPUs can make them faster than SHA-256 in pure software (SHA-256 uses 32-bit operations). However, most modern x86 CPUs have SHA-256 hardware acceleration (SHA-NI), so SHA-256 usually wins on real hardware.
Use SHA-384 when:
- A protocol specifies it (TLS 1.3 has SHA-384 cipher suites for higher-security configurations).
- You need a hash output that pairs with a P-384 ECDSA key.
Use SHA-512 when:
- You want the largest output size, for example to allow key derivation at very high security levels.
- You're on a 64-bit platform without SHA-NI and SHA-512 benchmarks faster than SHA-256 on your workload.
For general-purpose hashing, SHA-256 remains the safest default.
What about SHA-3?
SHA-3 (Keccak) was standardized in 2015 as a backup in case SHA-2 is ever broken. It uses a completely different internal construction (a sponge) so a weakness in SHA-2 would not automatically imply a weakness in SHA-3. SHA-3 is safe to use but is not a default in most ecosystems because SHA-2 has held up fine. If you have a choice with no other constraints, stick with SHA-256 for compatibility.
BLAKE3, BLAKE2
BLAKE2 and BLAKE3 are modern, fast hash functions with strong security properties. BLAKE3 can be faster than SHA-256 even on SHA-NI hardware thanks to parallelism. They're good choices for non-standardized use cases — content addressing in a private system, checksums for a fast tool — but they aren't as universally supported as SHA-256, so use SHA-256 when interoperating with arbitrary third parties.
Why none of the above are right for passwords
Cryptographic hashes are designed to be fast — the faster, the better for integrity checks and digital signatures. But fast is catastrophic for password hashing, because an attacker who steals your hashed-password database can brute-force common passwords at billions of attempts per second on modern GPUs.
Password hashing functions solve this in two ways:
- Deliberate slowness. Tunable cost parameter so you can make each hash take 100 milliseconds of CPU time — tolerable for one login, crippling for a brute-force attack.
- Memory hardness. Argon2 and scrypt require significant RAM per hash, which prevents attackers from parallelizing across cheap specialized hardware.
In 2026, the current recommendation for new systems is Argon2id. It won the Password Hashing Competition in 2015 and has held up under scrutiny. bcrypt is still acceptable, especially if your platform's Argon2 support is immature. PBKDF2-SHA-256 with at least 600,000 iterations is acceptable where FIPS compliance is required. Any of these is vastly better than SHA-256 alone.
The library you use will handle salting automatically — don't roll your own "concatenate salt and password and hash" scheme; you'll miss a detail that matters.
Practical picking guide
| Task | Use this |
|---|---|
| File integrity / download checksums | SHA-256 |
| Webhook signature verification (HMAC) | HMAC-SHA-256 |
| Content addressing in new systems | SHA-256 or BLAKE3 |
| Password storage | Argon2id (preferred) or bcrypt |
| Derive an encryption key from a password | Argon2id, or PBKDF2-SHA-256 (FIPS) |
| Cache key for an in-memory cache | Any — MD5 is fine, it's not adversarial |
| Legacy Git interop | SHA-1 (for now) |
| TLS 1.3 cipher suite | SHA-256 or SHA-384 per protocol |
How to verify you've picked the right one
When choosing a hash, ask two questions:
- Does an attacker control the input? If yes, the algorithm needs to be collision-resistant and second-preimage-resistant against real-world compute. MD5 and SHA-1 don't qualify.
- Is speed a problem or a feature? If the answer is "we want this to be slow so brute force fails," you are not doing general-purpose hashing — you're doing password hashing or key derivation. Use the right tool for that job.
That's the whole framework. Everything else is detail.