Skip to content

SHA-1 Hash Generator

Generate a SHA-1 hash of any text in your browser. SHA-1 is broken for collision-resistant uses; safe for non-security checksums.

SHA-1 is a cryptographic hash function published in 1995 by NIST, producing a 160-bit (40-hex-character) digest. The tool above computes SHA-1 in your browser; the input never leaves your machine.

Status: broken for collisions, otherwise intact

SHA-1’s collision resistance is broken. The 2017 SHAttered attack demonstrated two different PDF files with the same SHA-1 digest. Subsequent attacks have made finding collisions cheaper.

What remains intact:

  • Pre-image resistance. Given a digest, you still cannot recover the input.
  • Second-pre-image resistance. Given an input, you cannot find a different input with the same digest. (This is harder than finding any collision.)

What’s broken:

  • Collision resistance. An attacker can construct two different inputs with the same digest in feasible time.

The implications mirror MD5: SHA-1 is broken for code-signing, certificate fingerprints, and any use where an attacker chooses both inputs. It’s still adequate for accidental-corruption checksums and applications where inputs are not adversarially chosen.

Where SHA-1 still appears

  • Git internal object IDs. Git uses SHA-1 to identify commits, trees, blobs. Git has been migrating to SHA-256 since 2020, but SHA-1 is still the dominant default for existing repos.
  • HMAC-SHA-1. Used in some legacy authentication protocols (older AWS Signature versions, OAuth 1.0a). HMAC’s security depends on the underlying hash being collision-resistant for one of the inputs only — and SHA-1’s pre-image resistance is intact, so HMAC-SHA-1 is still secure.
  • TOTP / two-factor codes. RFC 6238 defaults to HMAC-SHA-1. Time-based one-time passwords (Google Authenticator) typically use SHA-1.
  • Older TLS certificates. Browsers deprecated SHA-1 certificates by 2017. Internal/legacy systems may still have them.
  • Legacy file checksums. Some software distributions still publish SHA-1 alongside SHA-256.

A worked example

Input:    "hello"
SHA-1:    aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

Input:    "Hello"
SHA-1:    f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0

Avalanche — one bit of input change scrambles the entire output.

SHA-1 vs MD5 vs SHA-256

AlgorithmOutputCollision-secureSpeed
MD5128 bitsNoVery fast
SHA-1160 bitsNo (since 2017)Fast
SHA-256256 bitsYesFast
SHA-512512 bitsYesFaster on 64-bit

For new code: use SHA-256. SHA-1 is acceptable for backward-compatibility with systems that require it (Git, TOTP, certain HMAC uses) but isn’t a default.

What SHA-1 isn’t

  • Not encryption. Hashes are one-way; SHA-1 has no inverse.
  • Not safe for password storage. Fast — billions of guesses per second on a GPU. Use Argon2 / bcrypt / scrypt.
  • Not safe for code-signing. Use SHA-256 or stronger.
  • Not adequate for new TLS certificates. Browsers reject them.

Common pitfalls

  • Using SHA-1 for new collision-sensitive applications. Even if “the threat model seems low,” code review will flag it. SHA-256 is the safe default.
  • Trusting SHA-1 software-distribution checksums. A determined attacker can construct a malicious binary that matches a target SHA-1. Modern publishers post SHA-256.
  • Comparing SHA-1 hashes loosely. Compare all 40 hex characters.
  • Confusing SHA-1 with SHA-2. SHA-1 and SHA-256/SHA-512 share a name but are different algorithms. SHA-256 is not a “newer SHA-1”; it’s a different design.
  • Using SHA-1 alone where HMAC-SHA-1 is needed. Bare SHA-1 doesn’t authenticate — sha1(secret + message) is vulnerable to length-extension. Use HMAC, which is properly designed.

For better algorithms, see SHA-256, SHA-512. For the multi-algorithm tool, see hash generator. For verifying file integrity, file hash.