Use SHA-256 by default. Use SHA-512 if you want extra margin or are hashing large files where its 64-bit word size performs better. Never use MD5 or SHA-1 for anything security-sensitive — both are cryptographically broken, though they're still fine for non-adversarial checksums like detecting accidental file corruption.
That's the short answer. Here's the actual reasoning, because "just use SHA-256" without context leads to people using SHA-256 in places where it's the wrong tool too.
What a hash function is actually for
A cryptographic hash takes arbitrary input and produces a fixed-length output (a "digest") such that:
- The same input always produces the same output (deterministic)
- A tiny change in input produces a completely different output (avalanche effect)
- You can't feasibly reverse the digest back to the input (pre-image resistance)
- You can't feasibly find two different inputs with the same digest (collision resistance)
That last property — collision resistance — is exactly what's broken in MD5 and SHA-1.
Why MD5 and SHA-1 are considered broken
MD5 has had practical collision attacks since 2004. Researchers can generate two different files with the same MD5 hash cheaply — which means MD5 can't be trusted for anything where an attacker controls the input, like verifying a downloaded binary hasn't been tampered with by someone who also controls the "official" copy.
SHA-1 followed the same path. Google and CWI Amsterdam demonstrated a practical SHA-1 collision in 2017 (the "SHAttered" attack), and it's been formally deprecated by NIST for digital signatures since 2011, with browsers dropping support for SHA-1 TLS certificates years ago.
Neither is "instantly crackable" in the sense of reversing a hash to find the input — that's a different property (pre-image resistance) and both still hold up reasonably well there. The break is specifically in collision resistance, which matters for signatures, certificates, and any scenario where two parties don't fully trust each other.
Where MD5/SHA-1 are still fine
Collision resistance only matters when someone is deliberately trying to forge a match. For non-adversarial use cases, MD5 and SHA-1 are still commonly used because they're fast and short:
- Checksums for accidental corruption — verifying a file downloaded correctly, not that it wasn't tampered with
- Cache keys / dedup keys — where speed matters more than cryptographic guarantees
- Git's object hashing (historically SHA-1, now migrating to SHA-256) — content-addressing, not adversarial security
If there's no attacker in the threat model, the "broken" property doesn't apply. If there is one — verifying downloads from an untrusted source, comparing user-submitted data, anything auth-adjacent — don't use them.
SHA-256 vs SHA-512: which one
Both are part of the SHA-2 family and neither has practical collision attacks. The difference is mostly performance characteristics, not security:
| | SHA-256 | SHA-512 | |---|---|---| | Digest length | 256 bits (64 hex chars) | 512 bits (128 hex chars) | | Word size | 32-bit | 64-bit | | Faster on | 32-bit / mobile hardware | 64-bit desktop/server hardware | | Typical use | TLS certs, Git (new), most APIs | Larger files, systems already on 64-bit-optimized paths |
In practice, SHA-256 is the default almost everywhere — it's what's baked into most APIs, package managers, and TLS. Reach for SHA-512 specifically when you're hashing large amounts of data on 64-bit server hardware and want the (modest) throughput gain, or when you want a larger digest for extra collision margin.
What hashing is not
Hashing is one-way and deterministic — it's for verifying integrity, not for storing secrets like passwords. A plain SHA-256 hash of a password is fast to compute, which is exactly the wrong property for password storage — it makes brute-forcing feasible with commodity hardware. Passwords need a slow, salted algorithm like bcrypt or Argon2 instead, not a general-purpose hash function.
Quick reference
- Verifying file integrity / checksums, no attacker involved → MD5 or SHA-1 is fine, but SHA-256 costs almost nothing extra
- Verifying downloads from an untrusted or public source → SHA-256 minimum
- TLS certificates, digital signatures, anything adversarial → SHA-256 or SHA-512, never MD5/SHA-1
- Hashing passwords → none of these — use bcrypt or Argon2
A Hash Generator that computes MD5, SHA-1, SHA-256, and SHA-512 side by side is useful for exactly this — comparing what each algorithm actually produces for the same input, entirely client-side, so nothing you're hashing (including sensitive files) ever gets uploaded.