SHA-1 spent two decades as the default fingerprint for downloads, source control objects and certificate signatures. It is now broken for collision resistance: an attacker with serious but attainable resources can build two different files that share one digest. That is fatal for signatures and survivable for a private integrity check, and the gap between those two cases is the whole point of this page.
Use the tool for what SHA-1 can still do honestly. Match a legacy checksum somebody published years ago, read a Git object id, or confirm that a copy you made yourself has the same bytes as the original. Do not use it to decide whether a file sent by a stranger is the file you were promised.
When a SHA1 hash generator is still the right tool
Every honest use of SHA-1 is a case where nobody is attacking you. A digest is a compact fingerprint of a byte sequence, and against accidental corruption, truncated downloads, bad cables and silent disk errors it works exactly as well as SHA-256 does. Random corruption has no idea how to build a collision.
The other legitimate case is compatibility. Git names every commit, tree and blob with a SHA-1. Older mirrors still publish SHA-1 lines beside their tarballs. If the value you are comparing against is SHA-1, you need SHA-1 to compare with it.
- Matching a SHA1 checksum published before a project moved to SHA-256.
- Reproducing a Git object id, which is a SHA-1 over a typed header plus content.
- Confirming a backup matches the original after a transfer you controlled end to end.
- Never for password storage, certificate signing, code signing or anything an adversary can influence.
Why SHA-1 is broken and what a SHA1 collision means
A cryptographic hash should make three things infeasible: recovering the input, finding a second input with the same digest, and finding any two inputs that collide. SHA-1 still holds the first two in practice and comprehensively fails the third. A 2017 research result produced the first public SHA1 collision, two PDF files with identical digests and different visible content, and 2020 work demonstrated a chosen prefix collision, where the attacker picks meaningful content for both halves.
Chosen prefix is the dangerous variant, because it lets somebody get a benign document signed and then present that signature as covering a malicious one. NIST formally retired SHA-1 for United States federal use in 2022. None of this makes a SHA-1 digest useless, but it does mean the digest is only as trustworthy as whoever chose the input.
Hashing text against hashing a file
Text mode encodes what you type as UTF-8 and hashes those bytes. The same visible characters produce different digests if one copy carries a byte order mark, a Windows line ending or a precomposed accent where the other uses a combining mark. When a text digest fails to match and the text looks identical, the culprit is almost always invisible.
File mode hashes the exact bytes on disk with no interpretation, no line ending translation and no trailing newline added. That is why file mode is the reliable way to verify file integrity: it compares what was written rather than what an editor chose to display.
How this SHA1 hash generator works in the browser
The tool calls crypto.subtle.digest with the SHA-1 identifier, the same native primitive the browser uses for its own bookkeeping, so the result matches what sha1sum, certutil or Get-FileHash print for the same bytes. Large files are read in eight megabyte slices to keep the tab responsive and give the progress bar something real to report.
Because the SHA1 hash generator runs in your tab there is no upload, no queue and no retention policy to read. One caveat is worth knowing: Web Crypto is only exposed in a secure context, so an https page or localhost is required. Opened from a raw file path the browser withholds crypto.subtle, and the tool says so rather than failing silently.
Comparing a digest against an expected value
Paste the checksum you were given into the comparison box. The tool trims whitespace and ignores case, since hexadecimal digests describe the same 20 bytes whichever way they are capitalised.
A mismatch usually means you hashed a different artefact, the download was truncated, or the published value is stale because the file was rebuilt. Only the rare fourth cause, deliberate tampering, is the one SHA-1 cannot rule out. When that possibility matters, ask the publisher for a SHA-256 value instead.
| Algorithm | Digest bits | Collision status | Use for new work |
|---|---|---|---|
| MD5 | 128 | Broken since 2004, seconds to collide | No |
| SHA-1 | 160 | Broken since 2017, chosen prefix since 2020 | No |
| SHA-256 | 256 | No practical attack known | Yes |
| SHA-512 | 512 | No practical attack known | Yes |
| CRC32 | 32 | Not a hash, trivially forged | Error detection only |
How to generate a SHA-1 hash
- 1
Choose text or file input
Switch to text mode to hash a string you type, or file mode to hash the exact bytes of a file on disk.
- 2
Add your input
Type or paste the text, or drop a file onto the drop area. The file is read locally and never uploaded.
- 3
Generate the digest
Press generate. The 40 character hexadecimal digest appears beside the progress panel when the run finishes.
- 4
Compare against an expected checksum
Paste the published value into the comparison box to confirm a match, then copy the digest if you need it elsewhere.
Related tools worth bookmarking
Sources and further reading
- RFC 3174: US Secure Hash Algorithm 1The IETF specification of SHA-1, including its padding rules and a reference implementation.rfc-editor.org
- NIST retires the SHA-1 cryptographic algorithmThe standards body that published SHA-1 explaining why it is withdrawn and what replaces it.nist.gov
- MDN: SubtleCrypto.digestDocumentation for the browser API used here, including its secure context requirement.developer.mozilla.org
Frequently asked questions
Common questions about the sha1 hash generator.
No, and neither is any raw hash function. Passwords need a slow, salted, memory hard function such as bcrypt, scrypt or Argon2 so guessing stays expensive. A bare SHA-1 digest can be tested billions of times per second on commodity hardware.
It depends who chose the file. Collisions have to be constructed deliberately, so a digest you computed over a file you created still detects corruption reliably. If an adversary controlled both the file and the published checksum, SHA-1 gives you no assurance.
Usually because you hashed a different artefact, for example the zip rather than the tarball, or a rebuilt release. Truncated downloads come next. For text, an invisible byte order mark or a Windows line ending changes the digest completely.
No. Hashing happens entirely inside your browser through the Web Crypto API, so the bytes never leave the machine. There is no server component, no temporary storage and no request carrying your data. Watch the network panel during a run to confirm it.
Yes, for anything new. SHA-256 has no known practical collision, runs at comparable speed and is what current standards specify. The only reason to reach for SHA-1 is matching a value that already exists in a system you cannot change.