SHA-1 Hash Generator (160-bit Legacy)

What Is SHA-1?

// Hash text using Web Crypto API (SHA-1 — legacy use only)
async function sha1(text) {
  const data = new TextEncoder().encode(text);
  const hash = await crypto.subtle.digest('SHA-1', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

await sha1('Hello, World!');
// → '0a0a9f2a6772942557ab5355d76af442f8f65e01'
// ⚠️ SHA-1 is broken — use SHA-256 for new work.

SHA-1 Examples

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author A Dev <dev@example.com> 1716854400 +0000
committer A Dev <dev@example.com> 1716854400 +0000

Initial commit

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKlL...
-----END CERTIFICATE-----

node-v0.12.7-linux-x64.tar.gz

(Paste the Google/CWI shattered-1.pdf file content via the File tab)

How to Generate SHA-1 Hashes

1. 1

   Paste text or drop a file

   Select the Text tab and paste any string — a commit message, certificate body, or legacy checksum input — into the input area. The SHA-1 hash updates as you type. For files, switch to the File tab and drag any file into the dropzone; the browser hashes it locally without any upload.

2. 2

   Copy the 40-character hash

   Click the Copy button next to the hash output. The full 40-character lowercase hex string goes to your clipboard. Use the Uppercase toggle if your legacy system expects uppercase hex — some old tools and Windows APIs default to uppercase.

3. 3

   Compare against a legacy fingerprint

   Switch to the Compare tab and paste two SHA-1 hashes side by side to confirm they match. Useful for validating a legacy publisher checksum, auditing a mirrored Git repository, or checking an old TLS certificate fingerprint from a document that predates SHA-256 adoption.

Technical Details

Algorithm: Merkle-Damgård construction, 80 rounds

SHA-1 processes input in 512-bit (64-byte) blocks, applying 80 rounds of bitwise operations grouped into four 20-round stages, each with a different logical function (Ch, Parity, Maj, Parity) and additive constant derived from square roots of small integers. The initial hash state is five 32-bit words (A–E), and the final hash is the concatenation of those words after the last block. Implementation defined in FIPS 180-1 (1995), superseded by FIPS 180-4 (2015) which formally includes deprecation language.

Output: 160 bits, 40 hex characters

Always exactly 40 lowercase hexadecimal characters (160 bits = 20 bytes, encoded as 2 hex chars per byte). The output length is fixed regardless of input size. Compared to SHA-256's 64 chars, the shorter output provides fewer bits of collision resistance — a key factor in why SHA-1 was broken before SHA-256.

Performance: fast but that is part of the problem

SHA-1 is fast — typically 400–700 MB/s in a browser using Web Crypto, competitive with SHA-256. For an attacker, this speed is an asset: a modern GPU cluster can compute billions of SHA-1 hashes per second, accelerating brute-force and collision searches. Speed is why SHA-1 (like MD5) must never be used for password storage — use bcrypt, scrypt, or Argon2 instead.

Standards: FIPS 180-1 (1995) — deprecated in FIPS 180-4 context

SHA-1 was standardized in FIPS 180-1 (1995), replacing the flawed SHA-0. NIST deprecated SHA-1 for digital signatures in NIST SP 800-131A (2011) and in FIPS 186-5 (2023) formally disallowed it for all digital signature generation. RFC 6194 (2011) documented known security considerations. The W3C WebCrypto API still includes SHA-1 for legacy interoperability reasons, which is how this browser tool can compute it.

Best Practices

Never use SHA-1 for security-sensitive operations

SHA-1 is deprecated for digital signatures, TLS certificates, code signing, password storage, and any workflow where collision resistance matters. The 2017 SHAttered attack demonstrated practical collisions. For all security uses, migrate to SHA-256 or SHA-3. The cost difference is negligible on modern hardware — SHA-256 is hardware-accelerated in all current CPUs and GPU pipelines.

SHA-1 for legacy fingerprint lookup is acceptable

If you need to verify a pre-2017 file checksum, look up a Git commit ID, or inspect an old certificate fingerprint for audit purposes, SHA-1 is appropriate. The hash itself is not being used to make a trust decision — you are just reproducing a known fingerprint for cross-reference. Document this explicitly in your audit logs: 'SHA-1 used for legacy reference only, not for security validation.'

Always hash UTF-8 bytes, not Unicode code points

SHA-1, like all hash algorithms, operates on bytes, not characters. The same string encoded as UTF-8 vs UTF-16 produces different hashes. This tool always encodes input as UTF-8 without BOM before hashing. If you need to match a system that uses a different encoding (Windows UTF-16-LE, Latin-1), you must pre-encode the input externally before comparing hashes.

Use constant-time comparison when verifying hashes in code

If you compare two SHA-1 hashes in code, use a constant-time equality check — Node.js crypto.timingSafeEqual(), Python hmac.compare_digest() — rather than naive string equality (=== or ==). Naive comparison leaks timing information that can theoretically allow an attacker to reconstruct the expected hash byte-by-byte. This is a defense-in-depth measure even for legacy SHA-1 verification.

SHA-1 FAQ