SHA-1 is the hash the industry spent a decade retiring and somehow still meets every day: in Git object IDs, TOTP codes and old checksum files. What broke in 2017, what that break does and does not affect, and the Git header quirk that makes its hashes look "wrong".
Broken, with an asterisk
The honest one-line status: SHA-1's collision resistance is gone, its preimage resistance is intact. Nobody can take a digest and recover an input, and nobody can find an input matching a given digest; what attackers can do since 2017 is manufacture two different inputs that share a digest, and steer their contents well enough to make both meaningful. That distinction decides where SHA-1 still works: verifying that a download matches a checksum from a trusted source is a preimage problem and still fine in practice, while accepting SHA-1 signatures over attacker-influenced content is a collision problem and has been exploitable for years.
How to use this generator
- Hash text: type or paste; the 40-character digest updates live, computed by the Web Crypto API (browsers keep SHA-1 available for exactly this kind of legacy work).
- Hash a file: drop it on the input pane; the raw bytes are hashed and the download button emits a
sha1sum-compatible checksum file. - Verify: paste the expected value; a mismatch names the first differing character, and a 64-character paste gets called out as the SHA-256 it probably is, since mixed-up algorithms are the most common cause of "checksum mismatch" panic.
How SHA-1 fell
The arc took twelve years. Wang, Yin and Yu reduced the theoretical collision cost from 2^80 to 2^69 in 2005, and the industry started its slow migration. SHAttered landed the first real collision in 2017, two PDFs with identical digests, after roughly 9 quintillion SHA-1 computations that Google's infrastructure ran in months. The 2020 chosen-prefix work made it worse: attackers no longer needed both files to be crafted together, they could target an existing prefix, the shape of attack that forged an MD5-signed CA certificate back in 2008. Cost then: tens of thousands of dollars in rented GPUs. Cost now: less every year.
The lesson we take from it, having watched MD5 run the same course: a first collision is not the beginning of the end, it is the end. Migration takes years, attacks only improve, and the time to leave a hash function is when the cryptanalysis starts trending, not when the exploit ships.
SHA-1 and Git
Git is the reason most developers still touch SHA-1 daily: every commit, blob and tree in a standard repository is addressed by one. Two details matter here. First, Git does not hash your file; it hashes blob <size>\0<content>, a type-and-length header followed by the bytes, which is why this page (or sha1sum) will not reproduce a blob ID from raw content and why that is not a bug. Second, Git's core has used "hardened SHA-1" since 2017: the SHA1CDC library detects the tell-tale patterns of the known collision techniques during hashing and rejects such objects outright, so pushing a SHAttered-style pair into a repository fails.
A full SHA-256 object format exists (git init --object-format=sha256) and works, but interoperability with the SHA-1 world, including most hosting platforms, remains the reason adoption is thin. For a repository, the risk calculus is genuinely different from certificates: an attacker who can commit colliding objects to your repo already has commit access, which was the game.
What SHA-1 is still fine for
Uses that survive the break share one property: no adversary gains anything from a collision. Deduplicating files against your own archive, verifying a vendor's legacy checksum, debugging a TOTP secret (the TOTP construction is HMAC-SHA1, and HMAC does not need collision resistance), matching torrent pieces, reproducing a Git object ID. For all of these, SHA-1 answers the only question being asked: are these the same bytes.
Everything with a security boundary goes to SHA-256 or better, and has for years: certificates, signatures, content authentication, anything where an attacker chooses inputs. And passwords never belonged to this family at all; the bcrypt page covers what they need instead.
SHA-1 questions
Why is SHA-1 deprecated?
Because collisions can be manufactured. Google and CWI published SHAttered in 2017, two different PDFs with the same SHA-1, at a cost of about 2^63 computations; the 2020 "SHA-1 is a Shambles" work brought chosen-prefix collisions, the practically dangerous kind, down to roughly 45,000 USD of GPU time, and hardware has only gotten cheaper since. A hash whose collisions can be bought breaks certificate issuance, signature schemes and anything else that relies on two parties never producing the same digest, so NIST formally retired SHA-1 and browsers stopped accepting SHA-1 certificates back in 2017.
What is the difference between SHA-1 and SHA-256?
SHA-1 produces a 160-bit digest (40 hex characters), SHA-256 a 256-bit one (64 characters); both are Merkle–Damgård constructions, but SHA-256 has a stronger round function and, decisively, no known collisions, while SHA-1 collisions are practical to manufacture. Speed is comparable, and on CPUs with SHA extensions SHA-256 is often faster in hardware. There is no scenario in new work where SHA-1 is the better choice; it survives purely as a compatibility requirement of older protocols and file formats.
Why does git hash-object give a different SHA-1 than sha1sum?
Because Git does not hash the file contents alone. A blob ID is sha1("blob " + size + "\0" + content): Git prepends a header with the object type and byte count before hashing. So sha1sum README.md and git hash-object README.md will never agree, and that is expected. To reproduce a Git blob ID by hand: printf "blob %s\0" $(wc -c < file) | cat - file | sha1sum. The same header scheme applies to trees, commits and tags, which is also why you cannot find a Git object ID by hashing raw file bytes in any online tool.
Is HMAC-SHA1 still secure?
Yes, oddly enough. HMAC does not depend on collision resistance, only on weaker properties of the underlying hash that SHA-1 still satisfies, so the published SHA-1 collisions do not translate into an HMAC-SHA1 forgery; RFC 2104-based schemes like TOTP (RFC 6238 defaults to HMAC-SHA1) remain sound. That said, it is a legacy default rather than a recommendation: new APIs sign with HMAC-SHA256, and the main reason to touch HMAC-SHA1 in 2026 is interoperating with something that already speaks it, OAuth 1.0 signatures being the classic example.
What is SHA-1 still used for today?
Git object IDs in the vast majority of repositories, TOTP two-factor codes (as HMAC-SHA1), the OpenPGP v4 fingerprint format, torrent piece hashes in the original BitTorrent format, and a long tail of enterprise software with SHA-1 checksums baked into manifests. All of these are either non-adversarial integrity checks or HMAC-style constructions where collisions do not bite. What you should no longer meet SHA-1 in: certificates, code-signing, password storage, or any new protocol design.
Can I compute SHA-1 in Python or on the command line?
Python: hashlib.sha1(b"data").hexdigest(). Node.js: crypto.createHash("sha1").update("data").digest("hex"). Linux: sha1sum file; macOS: shasum file (SHA-1 is its default algorithm); Windows: certutil -hashfile file SHA1. OpenSSL: openssl dgst -sha1 file. Some hardened environments disable SHA-1 in crypto libraries, in which case Python may raise ValueError: unsupported hash type unless the call passes usedforsecurity=False, the escape hatch added in Python 3.9 for exactly the legacy-checksum case.