SHA-1, and why it's deprecated
SHA-1 is a hash function published by NIST in 1995 (FIPS 180-1). Like any hash it maps input of any size to a fixed digest — here 160 bits, shown as 40 hexadecimal characters — and it's deterministic and one-way. For two decades it was the default for signatures, certificates, and version control.
The problem is collision resistance. A secure hash should make it infeasible to find two inputs with the same digest, but for SHA-1 that's no longer true: the 2017 SHAttered research produced a real collision, and a 2020 chosen-prefix attack lowered the cost further. Once collisions are practical, a hash can be forged, so SHA-1 was dropped from TLS certificates and formally deprecated.
It isn't useless — for checksums and legacy compatibility where no attacker is involved, SHA-1 still does its job. Just reach for SHA-256 anywhere security depends on it. Everything here runs locally via the browser's Web Crypto API.
When SHA-1 is (and isn't) OK
Non-adversarial uses where you only care about accidental change.
Anything where someone might try to forge a match on purpose.
MD5 vs SHA-1 vs SHA-256
| Algorithm | Digest size | Security status |
|---|---|---|
| MD5 | 128 bits | Broken |
| SHA-1 | 160 bits | Broken |
| SHA-256 | 256 bits | Secure |
SHA-1 produces a larger digest than MD5, but both are collision-broken. Migrate security-critical uses to SHA-256.
Where it still shows up
Verifying a legacy checksum
Confirm a download against a SHA-1 sum an older project published before SHA-256 became standard.
Working with Git objects
Reproduce or check the SHA-1 object IDs Git has historically used for commits and blobs.
Migrating off SHA-1
Compare SHA-1 and SHA-256 of the same input while moving an old system to a stronger digest.
Frequently asked questions
No — not for anything security-related. SHA-1 is collision-broken: the 2017 SHAttered attack produced two different PDFs with the same digest, and a 2020 chosen-prefix attack made forgeries far cheaper. NIST has deprecated it and browsers stopped trusting SHA-1 certificates years ago. Use SHA-256 for signatures, certificates, and integrity that matters.
Legacy compatibility. Plenty of older systems, file checksums, and protocols still emit SHA-1, and git historically used it for object IDs (it's migrating to SHA-256). For non-adversarial uses — matching an existing hash, detecting accidental corruption — it still works; just don't rely on it to stop a motivated attacker.
A collision attack occurs when two distinct inputs are engineered to produce the identical hash digest. In 2017 researchers demonstrated a practical collision (SHAttered) against SHA-1, which rendered it unsafe for digital certificates and signatures.
SHA-1 outputs 160 bits (40 hex characters); MD5 outputs 128 bits (32 hex) and SHA-256 outputs 256 bits (64 hex). MD5 is faster but weaker; SHA-256 (SHA-2 family) has no practical collision attack while SHA-1 and MD5 do. Pick SHA-256 unless you need SHA-1 for compatibility.
Yes — that's exactly what a collision is, and for SHA-1 it's been demonstrated in practice, not just in theory. That's why it can no longer be trusted to uniquely fingerprint untrusted content.
No. The digest is computed locally with the browser's Web Crypto API, so your input never leaves the page.