SHA1 Hash Generator

Paste or type any text, press Generate SHA1 Hash, and the SHA1 Hash Generator returns the 40-character hexadecimal SHA-1 digest of that text, with a copy button beside it. The hash is computed on the page when you press the button; the text is not sent anywhere. There's also an optional salt: tick "Include salt" and the salt string is appended to your text before hashing.

Text, salt and what the checkbox does

• Text. Anything you like, including multi-line input. Leading and trailing whitespace is kept as typed, and hashing is byte-exact, so "Hello" and "hello" give completely different results.
• Salt. When the page loads it fills the salt field with a random 32-character hex string (16 random bytes). You can replace it with your own value. The salt is only used when the checkbox is ticked; otherwise the field is ignored, though the form still requires it to be non-empty.
• Include salt. With the box ticked, the tool hashes text + salt, plain concatenation with the salt on the end. That's the convention many older password-storage schemes used. It's not an HMAC, so if you're matching against a system that uses HMAC-SHA1 the digests won't line up.

What comes back

A single lowercase hex string of 40 characters (160 bits). SHA-1 always produces the same digest for the same input, so this is a converter rather than a random generator: hash "abc" and you'll get a9993e364706816aba3e25717850c26c9cd0d89d every time, on this page or anywhere else.

Where SHA-1 still fits, and where it doesn't

SHA-1 was published by NIST in 1995 and was the default hash for TLS certificates, Git and countless checksums for two decades. In 2017 researchers produced the first practical collision (two different PDFs with the same SHA-1), and by 2020 a chosen-prefix collision cost roughly $45,000 in compute. Browsers stopped trusting SHA-1 certificates in 2017, and NIST has set the end of 2030 as the date SHA-1 is retired for all uses.

That means: don't use SHA-1 for digital signatures, certificate fingerprints or anything where an attacker could benefit from crafting a colliding input, and don't use a bare or salted SHA-1 for storing passwords (use bcrypt, scrypt or Argon2). It is still fine for non-adversarial jobs: Git object IDs, deduplicating files you control, checksum fields in legacy databases, and matching digests in systems you can't change. For new work, the SHA256 Hash Generator gives you the same interface with a current algorithm, and the SHA512 Hash Generator goes longer still.

Ways people use it

• Checking a legacy hash. A database migrated from a 2000s-era app stores salted SHA-1 passwords; hashing a known test password with its salt confirms which concatenation order the old code used.
• Git and content addressing. Quickly seeing what a string hashes to when debugging tooling that keys on SHA-1.
• Comparing against MD5. Run the same input through the MD5 Hash Generator and this page to show a class the difference in digest length (32 versus 40 hex characters).
• Generating a stable ID. Hashing a slug or URL to get a fixed-length key for a cache or filename.

For encoding rather than hashing, the Base64 Generator is reversible where this is not, and the Random Password Generator makes the kind of secret you'd actually want to hash. More of these are listed under all developer & test data tools.