What the SHA-1 Generator Does
The SHA-1 Generator computes the SHA-1 digest of any text via the browser's Web Crypto API. Paste input, run the transform, and the output is the 40-character lowercase hexadecimal digest. That is the whole tool — one algorithm, one output width, no options — because its role is precisely scoped: produce the digest where a legacy format, an old integration, or a historical record specifies SHA-1 and nothing else will do.
The framing matters more for SHA-1 than for its siblings. SHA-1 is cryptographically broken with respect to collisions: a practical chosen-prefix collision was demonstrated publicly in 2017 (the "SHAttered" attack), and the cost has only fallen since. This page exists because SHA-1 remains embedded in live systems — older package checksums, legacy certificate fingerprints, Git's current object hashing, some HMAC deployments — and reading those systems requires computing real SHA-1 digests. It exists not as a recommendation: nothing new should rely on SHA-1's collision resistance.
Where SHA-1 remains acceptable is narrow but real: preimage and second-preimage resistance (recovering or substituting a specific input) is still far beyond attack, so verification of known content against a recorded digest retains its value. The property that failed is collision resistance — the ability of two chosen, different inputs to share a digest — and chosen-collision attacks undermine signatures and certificates far more than download verification. Treat that nuance as the deciding line for any SHA-1 use you encounter.
How SHA-1 Works — and How It Broke
SHA-1, published by the NSA in 1995 as the successor to SHA-0, is a Merkle–Damgård hash over 512-bit blocks: the 160-bit internal state — five 32-bit words — passes through 80 rounds of bitwise mixing per block, with four round phases using different Boolean functions and a rotation schedule on the message words. The five words concatenated are the 20-byte digest, rendered here as 40 hex characters.
The structural weakness lives in the message-schedule rotation. Message words are expanded from the block and then rotated deterministically across rounds, and in 2005 researchers showed differential paths through the compression function that could be steered along that rotation — the first cracks. Twelve years of refinement produced the 2017 SHAttered demonstration: two genuinely different PDF files with identical SHA-1 digests, constructed for roughly the cost of a small GPU cluster. The attack class (chosen-prefix collisions) is the dangerous one, because an attacker who can craft two colliding documents can get one signed and later claim the other was.
Why the digest still computes honestly: the algorithm is deterministic and conforming everywhere. This tool calls crypto.subtle.digest("SHA-1", …) on your UTF-8 bytes — the same operation OpenSSL and every other library perform. The 40-character output for a given input is identical across all of them; the breakage is in the algorithm's guarantees, not in any implementation's correctness.
The migration story is why you are likely here: browsers rejected SHA-1 certificates years ago and ecosystems have re-signed old artifacts with SHA-256. Hashing here usually means reproducing an older system's digest — and the natural next step is recording the SHA-256 alongside it, which the multi-algorithm
Hash Generator produces in the same run.
Using the SHA-1 Generator
- Step 1 — Paste the input. Any text; the usual invisible-byte caveats apply, and trailing whitespace changes the digest completely.
- Step 2 — Run the transform. No options to set. The output is always 40 lowercase hex characters.
- Step 3 — Compare against the legacy record. A match confirms the content is unchanged from whatever the old system hashed. A mismatch means the bytes differ — or that you are comparing against a different encoding of the same text.
- Step 4 — Record the SHA-256 alongside it. For anything you are documenting or migrating, compute the modern digest too (the Hash Generator gives both in one pass) so the record does not depend on a broken algorithm going forward.
- Step 5 — Know the two questions SHA-1 can still answer. "Is this the same content that produced this recorded digest?" — yes, still reliable. "Did whoever signed this intend to approve this exact document?" — no longer answerable, because a skilled attacker can craft two documents that share the digest.
Common Use Cases
Verifying legacy package checksums. Older release manifests and mirrors published SHA-1 digests. Reproducing them confirms a downloaded artifact matches what was distributed at the time — a legitimate use, since you are checking for a specific known content, not defending against a chosen-collision adversary.
Reading Git object names. Git's blob, tree, and commit IDs are SHA-1 digests of typed object data. Computing a SHA-1 here (over the same byte format) is how you confirm what object a historical ID refers to, pending the ecosystem's SHA-256 transition.
Digest reproduction for audits. Compliance records from the 2010s frequently cite SHA-1 fingerprints of certificates, configurations, or documents. Auditing those records means recomputing them — this page reproduces the digest exactly.
Demonstrating why the migration happened. Hash a document here, then read the SHAttered background: two files can share this digest by deliberate construction. Tool plus history is the cleanest way to show a team why the old verification flow needs replacing.
Worked Example
Hash hello world:
2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
Forty characters — 160 bits — and identical to what sha1sum, OpenSSL, and every other implementation produce for those eleven bytes. Compare with the SHA-256 digest of the same input (b94d27b9…efcde9): different length, unrelated characters, same input. The algorithms are different functions, and this page computes the 1995 one faithfully.
The instructive comparison for this tool specifically is the empty input: SHA-1 of nothing is da39a3ee5e6b4b0d3255bfef95601890afd80709 — a value you will recognise the moment you see it in old configs, because half the legacy checksum files in the world contain it as the "no content" line. Clear the panel, run, and confirm the tool reproduces it.
Finally, the caveat made concrete: the SHAttered pair of PDFs share one digest while being entirely different documents. That is the failure mode — not that your digest is wrong, but that matching digests no longer prove identical intent. Verify known content with confidence; verify authorship with SHA-256 or a signature scheme instead.
Tips and Common Mistakes
- Do not put SHA-1 in anything new. The tool exists for reading legacy formats, not for creating new dependencies on them. New integrity checks, signatures, and identifiers should be SHA-256 or better.
- Verification of known content is still sound; chosen-document signing is not. Preimage attacks remain impractical, so "does this content match the recorded digest?" retains value. "Did this digest prove the author approved this document?" does not.
- HMAC-SHA1 is not the same hole. The HMAC construction resists the collision attack that breaks bare SHA-1. Existing HMAC-SHA1 integrations are not emergencies — but replacements should move to HMAC-SHA256.
- Git IDs are SHA-1 of typed content, not raw text. A commit hash covers a header line plus the object bytes. Hashing the message text alone here will not reproduce the ID — the format includes the type prefix and metadata.
- The usual byte-level suspects apply. Trailing newlines, CRLF, and BOMs change the 40 characters completely. Legacy files from Windows editors are prime suspects when a recorded digest will not reproduce.
Frequently Asked Questions
Is SHA-1 safe to use?
For new designs, no — its collision resistance is broken in practice, and any scheme where an attacker can choose two colliding inputs (signatures, certificates, file dedup of adversarial content) must move to SHA-256 or better. For verifying that known content matches a previously recorded SHA-1 digest, the guarantee still holds, because the attack requires crafting the colliding pair in advance. The safe summary: reproducing old digests, yes; building new guarantees, no.What was the SHAttered attack?
The 2017 public demonstration by researchers from CWI Amsterdam and Google of two chosen-prefix colliding PDF files — two meaningfully different documents with the same SHA-1 digest — built for a few thousand dollars of GPU time. It converted a long-theoretical weakness into a practical one, which is why browsers had already dropped SHA-1 certificates and ecosystems accelerated their migrations. The construction is repeatable; the cost has only declined.Why does Web Crypto still offer SHA-1 if it is broken?
Because legitimate legacy interoperability requires it — reading old formats, verifying historical records, existing HMAC deployments — and its preimage resistance remains intact for those uses. The API omits MD5 (where even preimage margins are eroding and no legacy format requires it in modern contexts) but keeps SHA-1. This tool follows the platform's lead and adds the framing both tools deserve.Is my Git commit hash affected?
Not by a realistic local attacker: forging a commit whose hash matches an existing one (a preimage attack) remains infeasible. The documented risk is deliberate collision crafting — constructing two objects in advance and getting one legitimised — which is why the Git project has an in-progress SHA-256 transition. Reading and verifying existing history is unaffected.Can I migrate a SHA-1 verification flow to SHA-256 incrementally?
Yes, and the standard pattern is dual-digest: record both SHA-1 and SHA-256 for a transition period (the
Hash Generator produces both in one run), verify against either, then retire the SHA-1 check once no producer emits it anymore. The failure mode to avoid is switching the verifier before all producers — which turns a migration into an outage.
Related Tools