Comparison
SHA-1 vs SHA-256: Why You Should Migrate Off SHA-1 in 2026
TL;DR
| SHA-1 | SHA-256 | |
|---|---|---|
| Digest size | 160 bits (40 hex chars) | 256 bits (64 hex chars) |
| Security | Broken for collision resistance (SHAttered 2017) | No known practical collision attack |
| Speed per MB | ~400 MB/s (modern CPU) | ~200 MB/s |
| Used by | Git hash-objects (legacy), some old TLS certs | TLS 1.3, Bitcoin, blockchains, modern Git (transitioning) |
| Status | Deprecated (NIST 2015) | Recommended (FIPS 180-4) |
The options in depth
SHA-1
Legacy hash — still in Git and some APIs, but don't choose it for new work.
SHA-1 is not completely useless — it remains acceptable for non-adversarial checksums (detecting accidental corruption, not malicious tampering) and for HMAC-SHA1 in legacy interop (HMAC's construction is more resistant to collision attacks). But for any new system: never use SHA-1. It fails the minimum security bar for 2026 deployments.
Good for
- ·Legacy system interop (some AWS S3 versions, older signing APIs)
- ·HMAC-SHA1 for legacy webhook verification
- ·Non-security checksums (file integrity against random bit flips)
Avoid when
- ·Any new deployment (use SHA-256)
- ·Certificate signing (browsers reject it)
- ·API key derivation or KDF (use SHA-256 with PBKDF2 or Argon2)
SHA-256
The modern gold standard — every new system should use it for hashing.
SHA-256 produces 256-bit digests. The output space (2^256 ≈ 1.16 × 10^77) is astronomically large. Preimage attacks are infeasible, and collision attacks require 2^128 operations — beyond any known hardware capability. SHA-256 anchors TLS 1.3, Bitcoin proof-of-work, and modern Git object-IDs. Use it.
Good for
- ·File integrity verification
- ·API key and token hashing
- ·TLS cert chains
- ·Digital signatures (RSA-PSS, ECDSA)
- ·Content-addressed storage
Avoid when
- ·Password hashing (use bcrypt / Argon2 — SHA-256 is too fast)
Which one should you pick?
→ Why is SHA-1 still in use if it's broken?
Git's entire data model is built on SHA-1 object IDs — changing the hash means rewriting every repo. The Git project chose SHA-256 for the eventual migration (the sha256 repository format), but the transition takes years.
Common pitfalls
- ⚠SHA-1 collision attacks work against chosen-prefix collisions, not against preimages. This means an attacker can create two different inputs that hash to the same value (collision), but they cannot reverse-engineer a specific input from its hash (preimage). This is why Git's security model was affected but not completely broken — and why HMAC-SHA1 is still considered acceptable in some contexts.
- ⚠Never use a single SHA-256 as a password hash. It's designed for speed, and password hashing needs the opposite — deliberately slow functions (bcrypt with cost factor 12, or Argon2id). A GPU can compute millions of SHA-256 hashes per second.
Frequently Asked Questions
Is SHA-512 better than SHA-256?
For most use cases: no. SHA-512 produces 512-bit output and is faster on 64-bit CPUs, but the 256-bit output of SHA-256 already exceeds the practical threat model. Use SHA-512 only if you need the larger output for specific compliance or cryptographic protocol requirements.