TK
Developer Tools

SHA-1 Hash Generator

Compute 160-bit SHA-1 hashes for text or files in your browser. Used by git for commit IDs and by older certificates. Considered deprecated for security; SHA-256 is the modern replacement.

Input
Hashes
Paste text to compute MD5, SHA-1, SHA-256, SHA-384, and SHA-512.

Inputs stay on this device. Every developer tool on TaskKit runs entirely in your browser. Tokens, payloads, and pasted text are not transmitted to TaskKit servers or third parties.

What this tool does

Computes the SHA-1 hash of any text or file in your browser, returning a 40-character hexadecimal digest. SHA-1 is a 160-bit hash function published by NIST in 1995 (FIPS 180-1), designed by the NSA. It is deprecated for security purposes: a practical collision attack ("SHAttered") was demonstrated by Google and CWI Amsterdam in 2017, and chosen-prefix collisions followed in 2019. SHA-1 is no longer considered cryptographically secure.

When SHA-1 is still around

  • Git object IDs. Every git commit, tree, and blob is identified by its SHA-1 hash. Git's object model is moving to SHA-256 (the --object-format=sha256 flag exists), but SHA-1 remains the default for the vast majority of repositories. The collision risk for commit IDs is real but managed: GitHub and other forges deploy SHAttered-style detection (the sha1dc library) to flag prepared collisions.
  • Subversion (SVN). Same reasoning as git, less effort underway to migrate.
  • Older TLS certificates. Browsers stopped trusting SHA-1-signed certificates in 2017, but legacy systems still produce them.
  • Existing code that hashes for non-security reasons. Cache keys, fingerprints, deduplication tables — all fine.

When SHA-1 is unfit

  • New TLS certificates, code-signing certificates, or document signatures. Use SHA-256 or SHA-384.
  • Password storage. Use a slow, salted hash like bcrypt or Argon2. SHA-1 is too fast and not designed for this.
  • Anything where an attacker can pick the input. A determined attacker with a rented cluster can produce a SHA-1 collision in days. If your security model lets the attacker influence what gets hashed, SHA-1 is broken.
  • Subresource Integrity (SRI). Browsers will accept SHA-1 in integrity attributes, but the spec recommends SHA-256 minimum.

Test vectors

From FIPS 180-2 and the SHA-1 reference suite:

  • Empty string "" → da39a3ee5e6b4b0d3255bfef95601890afd80709
  • "abc" → a9993e364706816aba3e25717850c26c9cd0d89d
  • "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" → 84983e441c3bd26ebaae4aa1f95129e5e54670f1
  • "The quick brown fox jumps over the lazy dog" → 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12

Notes

Why 40 characters? SHA-1 produces 160 bits = 20 bytes. 20 bytes × 2 hex characters per byte = 40 visible characters.

Why does git use SHA-1 if it's broken? Git uses SHA-1 as a content-addressable identifier, not a security primitive. The threat model is "two well-formed objects accidentally collide", which is still astronomically unlikely. The threat model is not "an attacker pushes a malicious commit that has the same hash as your real commit" — for that, GitHub etc. use sha1dc to detect SHAttered-style preparations and reject them. Migration to SHA-256 is happening but slowly because the install base is enormous.

Why does my SHA-1 differ from what sha1sum returns? Trailing newline. echo "hello" | sha1sum includes the \n. Pasting "hello" here doesn't. Use echo -n or the file picker.

  • Hash Generator — five hashes side by side
  • SHA-256 — the modern replacement for SHA-1
  • MD5 — the predecessor; even more thoroughly broken