SHA-1 Hash Generator

Generate a SHA-1 hash from any text — or drop in a file to checksum it, and paste a known hash to verify.

Input text

13 charactersUppercase output

Drop a file or click to hash its bytesComputes the SHA-1 checksum from the file contents, in chunks with progress

SHA-1 Hash (160-bit)

Verify against a known hash

About SHA-1

SHA-1 produces a 160-bit (40-hex-character) digest, computed here with your browser's native crypto.subtle over the UTF-8 bytes of your text. While still common in legacy systems and Git object IDs, SHA-1 is cryptographically broken for collision-resistance — prefer SHA-256 for new security-sensitive uses. Everything is computed locally.

Built and maintained by Meet Shah · Last updated 30 July 2026

What this tool is used for

Reading or reproducing a Git object identifier while working with repository internals.
Verifying a legacy artefact whose only published checksum is SHA-1.
Maintaining an existing HMAC-SHA1 integration where the construction remains sound.
Producing a fingerprint that matches an older system you cannot change.
Understanding why a protocol you are auditing is scheduled to migrate away from it.

Frequently Asked Questions

Is SHA-1 still safe?: No. SHAttered produced the first real collision in 2017, and the 2020 SHA-1 is a Shambles attack made chosen-prefix collisions practical for around $45,000 of compute. Browsers stopped trusting SHA-1 certificates in 2017 and NIST formally retired it in 2022.
Why does Git still use SHA-1?: For content addressing, not security, and Git ships a hardened variant that detects the known collision-attack patterns and refuses them. Git has a documented migration to SHA-256, but the SHA-1 object format remains the default for compatibility.
What is the digest size?: 160 bits, or 40 hex characters — larger than MD5's 128 but smaller than every SHA-2 variant. The structural weakness matters more than the length: the attacks exploit its compression function, not the birthday bound.
Is HMAC-SHA1 also broken?: Not in the same way. HMAC's security rests on the hash behaving as a pseudorandom function rather than on collision resistance, so HMAC-SHA1 has no practical break and still appears in TOTP and older AWS signing. New designs should still prefer HMAC-SHA256.
Where will I still encounter it?: Git object IDs, older TLS certificate chains, TOTP two-factor codes (RFC 6238 defaults to SHA-1), legacy JWT HS1 tokens, and Subversion. Recognising it is often about reading old systems rather than building new ones.
What did the SHAttered and chosen-prefix attacks actually demonstrate?: SHAttered produced two different PDFs with the same SHA-1 in 2017. The 2020 chosen-prefix attack was worse: it lets an attacker pick both inputs' beginnings, which is what makes forging a certificate or a signed document realistic rather than theoretical.
Is Git migrating away from it?: Yes — an object format using SHA-256 exists, though adoption is slow because every hash appears in tooling, hooks and URLs. Git also ships a collision-detection check that rejects the known attack patterns, which is why the 2017 PDFs cannot be committed silently.

Common errors and gotchas

Choosing it for a new design. Chosen-prefix collisions are practical, so it should not back any new integrity claim.
Assuming Git's use of it means it is safe generally. Git's threat model and its added defences are not yours by default.
Confusing collision resistance with preimage resistance. The first is broken here; the second is not.
Using it for passwords, where speed is the flaw rather than a feature.
Reading a length of 40 hex characters as proof of algorithm. Several formats share that length.