SHA-1 hash generator
Compute SHA-1 digests of text or files with the browser’s native WebCrypto, compare against an expected value, and see why Git still uses it.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
Paste the checksum published next to a download. Comparison ignores case and any spaces.
SHA-1 in one paragraph
Published by NIST in 1995, SHA-1 produces a 160-bit digest written as 40 hexadecimal characters. It was the default hash of the web for well over a decade — TLS certificates, Git object names, SSH fingerprints, code-signing — and it is now retired everywhere it guards against an adversary.
How it fell
| Year | Event |
|---|---|
| 2005 | Theoretical attack published, well below brute force |
| 2011 | NIST formally deprecates SHA-1 for digital signatures |
| 2017 | SHAttered: Google and CWI publish two different PDFs with the same SHA-1 |
| 2020 | Chosen-prefix collision demonstrated for roughly US$45,000 of compute |
| 2021 | Browsers and OS vendors complete removal from certificate validation |
A chosen-prefix collision is the dangerous kind: the attacker picks both documents in advance rather than accepting whatever gibberish falls out. That is what turns a research curiosity into a forged signature.
Where it is still used, legitimately
- Git. Object names are SHA-1, though Git now uses a collision-detecting variant that refuses known attack patterns, and SHA-256 repositories are supported.
- HMAC-SHA1. HMAC is not broken by collision attacks, which is why TOTP still specifies SHA-1 and why every authenticator app implements it.
- Legacy fingerprints. Older SSH and PGP key fingerprints, kept for compatibility rather than for security.
Git commit hashes will not match
A frequent surprise: hashing a file here gives a different value from
git hash-object. Git does not hash the file contents alone — it hashes a header
first:
blob <byte length>\0<contents>Commits, trees and tags each have their own header format. That is deliberate: it prevents a blob and a tree with the same bytes from colliding in the object database.
Verifying an old download
Plenty of archived software still lists only a SHA-1 sum. Checking it is better than checking nothing: it proves the file was not truncated or corrupted in transit. It does not prove nobody substituted the file, because an attacker who could do that could also edit the page listing the hash. Where a signature is available, verify that instead.
Move to SHA-256
For anything new, SHA-256 is the answer: no known weaknesses, hardware acceleration on every modern CPU, and universal support. The comparison table on this page shows the SHA-256 digest of the same input, one click away.
Questions
Is SHA-1 still safe to use?
Not against an adversary. Google and CWI produced two colliding PDFs in 2017, and a chosen-prefix collision followed in 2020. For non-adversarial identification — Git object names, legacy protocol fingerprints — it still works.
How long is a SHA-1 digest?
160 bits, written as 40 hexadecimal characters. Length is the quickest way to identify an unlabelled checksum: 8 is CRC-32, 32 is MD5, 40 is SHA-1, 64 is SHA-256.
Why does my Git commit hash not match this?
Git hashes a header plus the content — for a blob, the string "blob <length>\0" followed by the bytes. Hashing the file alone gives a different digest, which is by design.
Which algorithm should I use instead?
SHA-256 for anything new. It is in every platform, hardware-accelerated on modern CPUs, and has no known weaknesses. Switch with one click from the comparison table on this page.