What SHA-1 produces
SHA-1 maps any input to a fixed 160-bit value shown as 40 hexadecimal characters. It is best known as the algorithm Git historically used to name commits, trees, blobs, and tags — so every Git object ID you have ever seen is a SHA-1 hash. SHA-1 still appears in many legacy checksum, fingerprint, and certificate systems, making it useful to be able to compute one quickly.
How it works
This tool relies on the browser’s native Web Crypto API rather than a hand-rolled implementation. It encodes your text to UTF-8 bytes and calls:
const buf = await crypto.subtle.digest("SHA-1", bytes);The resulting ArrayBuffer is then formatted as lowercase hexadecimal. Because crypto.subtle.digest returns a promise, the hash is produced asynchronously and the display updates as soon as the calculation resolves. The output is identical to any conformant SHA-1 implementation — including the Git plumbing command git hash-object.
How SHA-1 works internally
SHA-1 processes the message in 512-bit blocks after padding. It maintains five 32-bit state words (H0–H4, initialised to specific constants). Each block goes through 80 rounds grouped into four passes of 20 rounds, each using a different nonlinear function:
- Rounds 0–19:
f(B,C,D) = (B AND C) OR (NOT B AND D)— a bitwise choice function - Rounds 20–39:
f(B,C,D) = B XOR C XOR D— parity - Rounds 40–59:
f(B,C,D) = (B AND C) OR (B AND D) OR (C AND D)— majority - Rounds 60–79: same XOR parity as rounds 20–39
Each round also applies a left-rotate by a fixed amount and adds one of four round constants (derived from square roots of 2, 3, 5, and 10). The five state words are added back to their input values, and the final 160-bit concatenation is the digest.
Git and SHA-1
Git uses SHA-1 to address every object in its store. A commit, tree, blob, or tag is identified by the SHA-1 of a header plus its content. Because SHA-1 collisions are now demonstrably possible (the SHAttered attack in 2017), Git has been adding support for SHA-256 object names as a long-term migration path — but the vast majority of repositories still use SHA-1 object IDs.
SHA-1 migration path
For any system still using SHA-1 for security-critical purposes, the migration path is straightforward:
- Password storage: if SHA-1 is being used for passwords, migrate immediately to bcrypt or Argon2 — SHA-1 is not just weak, it was never designed for passwords (it is fast and unsalted)
- TLS certificates: major browsers and CAs stopped accepting SHA-1 certificates in 2017; any remaining SHA-1 certificates should be re-issued with SHA-256
- Code signatures: SHA-1 code-signing certificates have been deprecated by major platforms; re-sign with SHA-256
- Git: if you need SHA-256 object names in Git, it is available in Git 2.29+ with
git init --object-format=sha256, though SHA-1 repositories remain the vast majority
Security note and known reference values
- Empty string:
da39a3ee5e6b4b0d3255bfef95601890afd80709 abc:a9993e364706816aba3e25717850c26c9cd0d89dhello world:2aae6c69f5d1a0fd9b9bed70ef5a5a4c4e2f7c6e
SHA-1 is no longer collision resistant: a practical chosen-prefix collision was published in 2020 by researchers at CWI Amsterdam and Google. It must not be used for digital signatures, TLS certificates, or any context where an attacker could submit two different inputs expecting the same hash. For those purposes choose SHA-256 or stronger. SHA-1 remains acceptable for non-adversarial integrity checks — detecting accidental corruption, computing Git object IDs, verifying legacy artifacts — where migrating is not yet practical. Everything runs in your browser via the Web Crypto API; nothing is uploaded.