The core numbers
| SHA-1 | SHA-256 | |
|---|---|---|
| Output size | 160 bits (40 hex chars) | 256 bits (64 hex chars) |
| Published | 1995 | 2001 (SHA-2 family) |
| Practical collision attack? | Yes — demonstrated 2017 ("SHAttered") | None known |
| Current status | Deprecated for security use | Current standard |
The larger output size isn't just "more digits for its own sake" — a longer digest means a larger space of possible outputs, which raises the theoretical difficulty of finding collisions. But the practical reason SHA-256 is trusted and SHA-1 isn't comes down to actual demonstrated attacks, not just digest length: SHA-1 has a real, working collision construction; SHA-256 doesn't.
What actually changed between the two, structurally
Both are part of the broader SHA family and share a similar Merkle–Damgård construction (processing input in blocks through repeated compression rounds), but SHA-256 uses a larger internal state, more rounds, and different round constants — the accumulated effect of over a decade of additional cryptanalysis experience since SHA-1's design. This isn't merely "SHA-1 but bigger" — it's a meaningfully hardened design informed by weaknesses discovered in SHA-1's era.
Migrating a system still using SHA-1
- Certificates and TLS: modern browsers already reject SHA-1-signed certificates — if a system still issues them, it's likely already failing modern clients, not just theoretically at risk.
- Password/API-key storage: if SHA-1 is being used as a general-purpose hash for anything security-sensitive (not passwords specifically — see Password Hashing for why neither is appropriate there), migrating to SHA-256 is usually a drop-in replacement, since both take arbitrary input and produce a fixed digest — the integration surface is the same, just a different function call.
- Existing stored SHA-1 digests: these can't be "upgraded" to SHA-256 without the original input — if you need SHA-256 digests for existing data, you have to re-hash the actual source data, not transform the old SHA-1 output.
Common mistakes
- Assuming SHA-1 is "fine for internal use" because it's not customer-facing. If an adversary might ever want to forge a match against a SHA-1-verified value, internal-only doesn't reduce the risk.
- Trying to convert an existing SHA-1 digest directly into a SHA-256 digest. This isn't possible — hashing is one-way, so producing a SHA-256 digest for the same data requires access to and re-hashing the original input, not the old hash.
- Treating the migration as purely academic. SHA-1-signed certificates are already actively rejected by modern browsers — this is a live compatibility issue, not just a future risk.
FAQ
Is SHA-256 just a longer version of SHA-1?
Not exactly — while both are part of the broader SHA family and share a similar overall structure, SHA-256 uses a larger internal state and additional rounds informed by cryptanalysis of SHA-1's weaknesses, not simply a length increase.
Can I convert old SHA-1 hashes to SHA-256 without the original data?
No — hashing is one-way; producing a SHA-256 digest requires re-hashing the actual original input, not transforming the existing SHA-1 output.
Do browsers still accept SHA-1-signed certificates?
No — modern browsers reject them outright; this is an active compatibility failure today, not just a theoretical future risk.
Generate and compare SHA-1 and SHA-256 digests side by side with the Hash Generator — entirely client-side.