SHA1 Hash Generator

Paste any text into this SHA1 hash generator and you get back a fixed 160-bit digest, shown as 40 characters of Hex or as Base64, with an optional HMAC when your protocol needs a secret key. It runs the calculation in your browser, so the string you hash never has to leave your device, and the lowercase or uppercase result is ready to compare against a published checksum.

Using a SHA1 Hash Generator to Create a Message Digest

A SHA1 hash generator turns an input string into a message digest: a short, fixed-length fingerprint of the bytes you typed. The Secure Hash Algorithm behind it was published by the NSA in 1995 and standardized by NIST, and it always returns the same digest for the same bytes. Change one character and the whole digest changes. That predictable behavior is why a SHA-1 hash is still used to confirm that two copies of some data are identical. Run the free md5 hash generator whenever you need another one — it only takes a few seconds.

What a SHA-1 hash looks like

Every SHA-1 digest is 160 bits long. Written as hexadecimal, that is a run of 40 hex digits (each one carries 4 bits), whatever the size of the input. A one-word input and a whole novel both produce a value of the same length. If you need a different notation, the same bytes can be written as Base64, which comes out at 28 characters including one padding sign.

Input encoding: UTF-8, UTF-16 and line endings

SHA-1 never sees your "text"; it sees bytes. The input encoding you choose decides which bytes those are, so UTF-8 and UTF-16 versions of the same words give completely different digests. Line endings and trailing spaces count too: a Windows \r\n break hashes differently from a Unix \n break. When a result does not match the one you were given, an invisible newline or the wrong encoding is the cause far more often than a faulty tool.

How to Calculate SHA1 Hash Values Online

Follow these steps to calculate a SHA1 hash from a string: Generate exactly what you need with the free password hash generator, no account, install, or sign-up required.

1. Type or paste your text into the input box and select the exact input encoding (UTF-8 for almost everything).
2. Choose the output format: lowercase Hex, uppercase Hex or Base64.
3. Turn on HMAC only if a shared secret key is part of the protocol you are following.
4. Click the hash button, then compare the complete 40-character digest, not just the first few characters.

The output is a one-line hash value, and SHA1 hashes like it can be copied straight into a manifest, a ticket or a comparison. This free online tool also works as a quick digest generator for short strings during development, though for large files a dedicated file checksum utility is the better fit.

Worked Example: How One Character Rewrites the SHA-1 Hash

Take the string hive-backup-v7.2. Hashed as UTF-8 text, the SHA-1 digest is 5c124575e4a05e9d0119f1ecda497db77f74b774. The table below shows what happens when the input is altered in the smallest ways possible. Run the free sha512 hash generator whenever you need another one — it only takes a few seconds.

Nothing about the first digest hints at the other four, even though the inputs are nearly identical. In Base64 the first digest is XBJFdeSgXp0BGfHs2kl9t390t3Q=. This is the avalanche behavior that makes a SHA-1 checksum good at spotting tampering or file corruption: even a one-bit change is impossible to miss. Running HMAC-SHA-1 with the key k3y-9 changes the result again, to 69ba5e6a6401b308a93660d02050263ca9fa1829, because the secret key becomes part of the calculation.

How the SHA-1 Hash Function Works

SHA-1 is a cryptographic hash function from the SHA-2 family's older sibling, specified in FIPS 180-4. It pads the message, splits it into 512-bit blocks and mixes each block through 80 rounds of bitwise operations, updating five 32-bit words as it goes. Those five words, joined together, form the 160-bit result.

The size of the output sets the theoretical security level. For a hash with an \(n\)-bit digest, the effort needed to find any two inputs that collide by brute luck is about:

$$2^{n/2} = 2^{160/2} = 2^{80}$$

That is roughly 1.2 × 10²⁴ operations, which looked comfortable in 1995. Cryptanalysis has since found shortcuts that cut the real effort far below this figure, which is the subject of the next section.

Is SHA-1 Still Secure? Collision Weaknesses and Legacy Use

A collision is a pair of different inputs that share one digest. SHA-1 was designed to be collision resistant, but researchers started publishing weaknesses around 2005, and NIST told agencies to move away from it by 2010. In 2017 the SHAttered attack produced two different PDF files with an identical SHA-1 hash, proving the break was practical for well-funded attackers. Browsers then stopped trusting SHA-1 certificates, and SSL certificates and digital signatures moved to stronger algorithms.

Why Git still uses a SHA-1 digest for commits

Git names every object in a repository, including commits, with the SHA-1 digest of its content, so hashing the same bytes here reproduces a legacy identifier. In that setting the hash function works as a checksum for identification, not as a defense against an adversary, which is why it survived. Even so, version control projects are adding SHA-256 support, because the assumption that nobody will craft a collision no longer holds.

Can you decrypt a SHA1 hash?

No. A hash is not encryption, and the SHA1 hash function is a one-way function: the original text cannot be computed back from the digest, so the process is irreversible. Sites that advertise to "decrypt" a digest are really searching a lookup table of known inputs, or running a brute force guess through every possible combination. A short, common word falls in seconds, while a long random string never will. If you came looking for a way to SHA1 encrypt a secret so you can read it later, you need real encryption, not a hash.

SHA-1 for passwords: what to use instead

SHA-1 was historically used for password hashing, usually with a salt added to the password before hashing. Today that is a poor choice: SHA-1 is fast, which helps anyone who is guessing. Store every password with a slow, purpose-built scheme such as bcrypt, scrypt or Argon2, and let each user have a unique salted record. Hashing a password with SHA-1 here is fine for checking an old record, not for protecting a new one, and the same goes for passwords stored in a database.

Checking a Legacy Manifest with this SHA-1 Hash Tool

A network technician is about to apply an old vendor update to rack 14's switches. The 2019 release notes list one integrity line per build, and for build rack14-fw-2.8.31-rel the manifest gives the SHA-1 value 5c3052623068f8489d30b27c73d6509d58ecd4d4. Before trusting the tag string in the deployment script, the technician wants to confirm it matches what the vendor hashed.

They paste rack14-fw-2.8.31-rel into the tool, keep UTF-8 as the input encoding, pick lowercase Hex and click the hash button. The digest that comes back is d9a0d85183f2b9ebdfe80c93999c481a40c14d22. It does not match the manifest, and the first characters already differ, so this is not a copy-and-paste slip at the end of the line.

The vendor's script probably produced the value with echo, which appends a newline. The technician adds a single line break after the string and hashes again. This time the output is 5c3052623068f8489d30b27c73d6509d58ecd4d4, identical across all 40 characters, which confirms the manifest was built from the tag plus a trailing \n.

Because NIST has advised replacing SHA-1 since 2010, the match proves the string is unchanged by accident, not that the manifest is authentic. So the technician records the check as "legacy integrity only" and does two things next: the deployment script now hashes the tag with a trailing newline to reproduce the vendor value, and the SHA-256 digest of the same string is added to the team's own runbook for every future build.

The whole check takes one run with the wrong input and one with the right bytes, which is the pattern worth remembering: when a SHA-1 result is off, change the bytes before you doubt the hash.

SHA1 vs MD5, SHA-256 and SHA512

When you pick a hash tool, the family matters more than the brand. MD5 produces 128 bits and has been broken for longer than SHA-1, so it should never be chosen over either. SHA-256 and SHA512 sit in the SHA-2 line and remain approved, with SHA256 the standard replacement and SHA512 often faster on a 64-bit machine. Compare the options side by side:

You can verify any row by counting the characters of a result: an SHA-256 digest of the same example text, 0660abc5dc..., is 64 hex characters long.

When a SHA-1 Checksum Is Still Useful

Despite its age, SHA-1 still earns a place in a few safe jobs. All of them involve data verification where no attacker is trying to forge a match, and they need legacy compatibility with systems that already store SHA-1 values:

• Checking that a download is unaltered against a checksum published years ago.
• Creating unique identifiers for cache keys or deduplication.
• Matching values against older tools, build systems and protocols that specify SHA-1 for compatibility.
• Using a SHA-1 tool to verify a string you were given before migrating to a stronger algorithm.

For anything new, whether signatures, certificates or adversarial settings, pick SHA-256. Plain SHA1 checksums also prove nothing about who sent the data; an HMAC adds a secret key, but only if both sides follow the surrounding protocol exactly.

Other Output Formats and Random SHA1 Hashes

Some workflows need more than a lowercase Hex string. A SHA1 generator can show uppercase or lowercase Hex, binary, octal or a custom radix, and a few tools produce random SHA1 values or hashes that match a wildcard pattern, such as digests starting with five zeros. Those outputs are the same 160 bits written in a different base; the sha1 digest underneath never changes. The same sha-1 hashes can also feed a quick hash tool pipeline when you convert values between formats.

Frequently Asked Questions

What is SHA-1 used for?

SHA-1 is a legacy cryptographic hash function still used for Git commit identifiers, some legacy checksums, and older authentication protocols. It's been deprecated for security purposes since 2017, when researchers demonstrated a practical collision attack (the SHAttered attack) -- use SHA-256 or stronger for anything requiring collision resistance.

Is SHA-1 safe for hashing passwords?

No -- SHA-1 (like every hash function on this page except the dedicated password-hashing tools) is designed to be fast, which is exactly the wrong property for password storage: fast hashes let an attacker try billions of guesses per second on stolen data. Use this site's Bcrypt Generator, Password Hash Generator's Argon2id notes, or a dedicated slow KDF (PBKDF2, scrypt, Argon2) for anything storing real user passwords.

Is the output the same every time for the same input?

Yes -- SHA-1 is deterministic: the exact same input text always produces the exact same hash, with no randomness involved. That's what makes it useful for integrity checks (comparing two files or messages) but unsuitable on its own for password storage, where each user needs a unique, unpredictable salt.

Can a hash be reversed back to the original text?

Not directly -- hash functions are one-way by design. The only practical way to "reverse" one is to guess inputs and hash each guess until a match is found (a dictionary or brute-force attack), which is exactly why fast hashes like this one are unsuitable for protecting secrets on their own.

Is my text sent anywhere?

No. The hash is computed entirely in your browser -- nothing is transmitted to a server or stored.