SHA-1 hash generator
SHA-1 has been thrown out of every job that involves trusting a stranger, and your own Git history is still built out of it. Type or paste something in and the 40 hexadecimal characters are worked out in this tab, with nothing uploaded. The useful question is not whether SHA-1 is broken but which of your own uses the break actually reaches, which is what the rest of this page sorts out.
This box hashes text. For the checksum of a file, a folder, or a download you are verifying, that is the Files and Verify tools in Rocket Hash — a web page has no access to your disk.
The algorithm is worked out from the length of what you paste, then compared with the digest of the text above. To check a checksum against a file, use the Verify tool in the Mac app — it reads the file itself and gives you a plain match or no-match verdict.
SHA-1 sits in a strange position. No new system should use it, browsers reject it outright, the certificate authorities gave it up years ago — and you almost certainly relied on it a dozen times today without noticing, because it is the name under which every object in every Git repository is stored. Forty hexadecimal characters, 160 bits, and three decades of infrastructure stacked on top of them.
How SHA-1 came apart
It did not happen suddenly. The theoretical cracks opened a decade before anybody produced an actual pair of files, which is why the deprecation notices ran years ahead of the demonstration.
| Year | What happened |
|---|---|
| 1995 | SHA-1 is published as a federal standard and becomes the default almost everywhere |
| 2005 | Xiaoyun Wang's team shows a collision is far cheaper than brute force — on paper, not yet in practice |
| 2011 | NIST deprecates SHA-1 for digital signatures, six years before anyone breaks it for real |
| 2017 | SHAttered: two different PDF files with the same SHA-1 digest, at a cost of roughly 110 GPU-years |
| 2017 | Chrome and Firefox stop accepting SHA-1 certificates outright |
| 2020 | A chosen-prefix collision for about $45,000 of rented GPU time, used to forge a PGP signature |
| 2030 | NIST's announced end date for SHA-1 in federal use |
The 2020 result is the one that settled the argument. A plain collision gives an attacker two files they built from scratch together; a chosen-prefix collision lets them start from two meaningfully different beginnings — two different contracts, two different certificates — and then compute the filler that drags both to the same digest. That converts a laboratory curiosity into a document-substitution attack, at a price any motivated party can pay.
Collisions are broken; recovering an input from a digest is not, and neither is HMAC-SHA-1, which does not depend on collision resistance and is still considered sound. The MD5 page sets out the difference between the two properties in full.
Why Git still runs on SHA-1
Git names every blob, tree, commit and tag by its SHA-1, and that name is woven into the entire object database — rewriting it is not a patch, it is a new storage format. Git does now support repositories with SHA-256 object names, but the support is still marked experimental and SHA-256 repositories cannot yet talk to SHA-1 ones, so in practice the world's history remains SHA-1.
That is less alarming than it sounds, because Git is using the digest as an identifier for content rather than as a claim about who wrote it. To exploit a collision, somebody has to author both objects and then get one of them into your repository — which matters enormously for a project that accepts files from strangers, and hardly at all for your own working copy. The sharper edge is signed tags and signed commits, where a signature over a SHA-1 inherits the weakness of the SHA-1.
Git also hedged. Since 2017 it has used a hardened SHA-1 that watches for the arithmetic patterns a collision attack leaves behind and refuses to produce a digest for such an input, rather than quietly hashing it. For every ordinary file the output is identical to standard SHA-1, which is the only reason such a change was possible at all.
Why git hash-object gives a different answer
Take the plain SHA-1 of a file, then look the same file up by its object id in a Git repository, and you have two different 40-character values. Neither is wrong. Git does not hash the file's contents — it hashes a short header naming the object type and its length in bytes, immediately followed by the contents.
Spelled out, the header is the word blob, a space, the length in decimal and a zero byte, all of it in front of your first real byte. So a Git object id is a genuine SHA-1, of something slightly larger than your file, and no amount of re-reading the file will bring the two into line. The practical rule is that Git's names only ever compare against other Git names. A 40-character value from anywhere else — a release page, an old manifest, a colleague — compares against the plain SHA-1 of the bytes on disk, which is what the LEGACY row of Rocket Hash gives you. Why two tools give different hashes covers this case and the five other reasons a pair of digests refuses to line up.
Where SHA-1 has already been switched off
If something in front of you insists on SHA-1 today, it is usually a system nobody has touched in a while. Browsers rejected SHA-1 certificates in early 2017. OpenSSH disabled the SHA-1-based ssh-rsa signature algorithm by default in version 8.8, which is why a server that has not been updated since will refuse your key with no obvious explanation. Package managers, code-signing services and TLS have all moved on.
A publisher offering only a SHA-1 in 2026 is telling you something about how closely they watch this. If a SHA-256 is published for the same file, that is the value to check — verifying a download covers how.
What SHA-1 is still legitimately doing
Quite a lot, almost all of it as a label rather than a promise. The six-digit code your authenticator app produces is HMAC-SHA-1 in most implementations, and it is fine there for the reason above. BitTorrent names every piece of every version-1 torrent by its SHA-1, which is why the info hash in an old magnet link is 40 hexadecimal characters; version 2 of the protocol switched to SHA-256. Caches, deduplication buckets and ETags use it because it is short, fast and well supported.
One question separates all of those from the broken cases: does an adversary get to choose the bytes being hashed? When they do not, SHA-1 is a serviceable 160-bit identifier with a very long tail of tooling behind it. When they do, a matching digest says only that the file matches a value the attacker was free to arrange. Whether SHA-1 is still safe goes through the cases individually, and which algorithm to use is the short answer if you are choosing one today.
If you were handed 40 characters
Length gives the algorithm away, and in common use 40 hexadecimal characters means SHA-1 and nothing else — so when a page offers a bare “checksum” and it is 40 characters wide, you know what to compute without asking. SHA-1 is lucky in that respect: the genuinely ambiguous widths are 64 and 128 characters, where a SHA-2 and a SHA-3 digest are indistinguishable by eye. Telling which algorithm a checksum uses covers how to settle those.
SHA-1 outside a browser tab
When a 40-character value refuses to match, the first thing worth ruling out is your own tool. Every algorithm in Rocket Hash is verified against the official NIST test vectors and cross-checked against independent reference implementations, so a disagreement is a fact about the file rather than about the software. In its list SHA-1 sits under LEGACY next to MD5, well away from the recommended digests — the honest label for it, and a useful one, because it makes SHA-1 hard to reach for by accident while leaving it one click from your clipboard when an old system insists.
Both of the jobs an old SHA-1 usually turns up in start with a file, which is where a tab stops. The first is volume: a manifest written in 2011 with a thousand SHA-1 lines in it is a folder job, not a file job, and the Files tool takes the folder whole — a row per file showing the name, the folder it came from and the digest, each file read exactly once, a count ticking along the bottom as it goes, and a shasum-compatible manifest at the end to set beside the old one. The second is the comparison itself: paste 40 characters into the Verify tool, drop the file they are supposed to describe, and the answer is a green seal and a sentence instead of two strings you would otherwise read character by character at the end of a long afternoon.
Text hashing is free, which is enough for the case this page mostly serves: one short string, one digest, one comparison. Generating a SHA-1 on a Mac walks through a string and a file in turn, and checking files against a manifest is the page for the thousand-line version.
Frequently asked questions
Is SHA-1 still safe to use?
Not for anything where somebody might want to deceive you — signatures, certificates, proving a download is authentic. Collisions have been publicly demonstrated since 2017 and cost around $45,000 to arrange since 2020. SHA-1 remains reasonable as an internal identifier or cache key, where nobody hostile chooses the content being hashed.
How long is a SHA-1 hash?
40 hexadecimal characters, which is 160 bits or 20 bytes. Nothing else in common use is 40 characters, so a checksum of that length is a SHA-1. For comparison, MD5 is 32 characters and SHA-256 is 64.
Why does git hash-object give a different SHA-1 than the checksum of the file?
Because Git does not hash the file's contents alone. It hashes a short header giving the object type and the content length, followed by the contents, so the resulting object name is a SHA-1 of slightly more than your file. Both values are correct SHA-1 digests — of different inputs — and a Git object id only ever compares against another Git object id.
Has SHA-1 actually been broken, or is it just theoretical?
Actually broken. In 2017 a team published two different PDF files with the same SHA-1 digest, at a cost equivalent to about 110 GPU-years. In 2020 a cheaper chosen-prefix attack was used to forge a PGP signature for roughly $45,000 of rented computing time.
Can a SHA-1 hash be reversed or decrypted?
No. SHA-1 discards information, so there is nothing to decrypt, and no practical attack recovers an input from a digest. Sites that appear to reverse SHA-1 are looking the digest up in a table of previously hashed common inputs, which works for short passwords and nothing else.
Is SHA-1 better than MD5?
Meaningfully harder to attack, and still on the wrong side of the line. An MD5 collision takes a second on a laptop; a SHA-1 collision takes a serious budget. Both fail the same property, so if you are choosing an algorithm rather than matching a published value, the answer is SHA-256.
What should I use instead of SHA-1?
SHA-256, unless a specification tells you otherwise. It is the default nearly everywhere, it is accelerated in hardware on Apple Silicon so it usually costs nothing in speed, and no collision has ever been found. SHA-512 and SHA3-256 are also sound choices if you have a reason to prefer them.