To get a SHA-1 hash, run your input through the SHA-1 algorithm to produce its fixed 160-bit digest, then write the resulting 20 bytes as 40 lowercase hexadecimal characters or 28 standard padded Base64 characters. The output is always the same length regardless of input size, because the algorithm is defined to emit exactly 160 bits for any message. When you get a SHA-1 hash from text or a file, every byte of the input participates, including invisible ones like spaces, line endings, and the multi-byte UTF-8 sequences behind accented letters, emoji, and non-Latin scripts. That is why two strings that look identical on screen can produce different digests. The browser-based Sha1 Hash Generator computes the digest locally using the algorithm specified in NIST FIPS 180-4, so the bytes you choose never leave your machine. This is the right tool when a legacy download page, archive catalog, or old integration publishes a SHA-1 checksum and you need to compare exact bytes against it. For any new security-sensitive work, choose SHA-256 or SHA-512 instead.
What the SHA-1 Hash Actually Looks Like
SHA-1 was published by NIST as part of the Secure Hash Standard and is documented in FIPS 180-4. Its job is straightforward: take a message of any length, run it through 80 rounds of mixing across five 32-bit state words, and emit a 160-bit digest. Because the digest has a fixed width, the size of your input does not change the length of the result. It changes only the number of 512-bit blocks the algorithm processes internally before the final state is read out.
The 160 bits come out as 20 raw bytes. Those 20 bytes can be written in two standard ways:
- Lowercase hexadecimal: each byte becomes two hex characters, giving exactly 40 characters. This is the format most legacy checksum files use.
- Standard padded Base64: the 20 bytes are re-encoded using the RFC 4648 alphabet, which yields 28 characters. The result ends with a single '=' because 20 bytes is not divisible by 3.
Both representations describe the same digest. They are not different hash values, and one cannot be turned into the other without first decoding it back to the raw 20 bytes. Choosing the right format is purely about matching what the consuming system expects.
When SHA-1 Is the Right Choice (and When It Isn't)
SHA-1 is collision-broken. Researchers have demonstrated practical chosen-prefix collisions, meaning attackers can construct two different files with the same SHA-1 digest under realistic conditions. Because of that, RFC 6194 explicitly warns against using SHA-1 for any new digital signature, certificate fingerprint, or integrity promise that an adversary might want to forge.
That does not make SHA-1 useless. It remains the right answer for:
- Matching a published legacy checksum on an older download page or archive catalog.
- Comparing a file against an internal SHA-1 reference that some old system still records.
- Reproducing a digest that another script or library already produces with SHA-1, so two systems can agree.
- Debugging a workflow that already depends on SHA-1 outputs and needs a quick cross-check.
It is the wrong answer for:
- New digital signatures, certificate fingerprints, or tamper detection in adversarial settings.
- Password storage. A plain SHA-1 is far too fast. Attackers can test billions of guesses per second against a stolen hash file. Use a salted, deliberately slow scheme such as Argon2id, scrypt, or bcrypt, implemented by the account system.
- Any design where you control the algorithm choice and want modern security margins.
For new security-sensitive work, the SHA256 Hash Generator and the Sha512 Hash Generator are the right starting points. Both keep the same in-browser workflow but emit a longer, currently safe digest.
Get a SHA-1 Hash From Text or a File in Three Steps
- Choose UTF-8 text or file bytes and provide the exact input without normalizing whitespace. If you are hashing a typed string, paste or type it directly into the text field. The tool encodes the visible string as UTF-8 before hashing, so accented characters, emoji, and non-Latin scripts use their actual multi-byte forms. If you are hashing a file, select it from disk. The tool reads its raw bytes up to the documented 100 MB limit and never sends them anywhere. Do not trim leading or trailing whitespace, do not re-encode the file, and do not let a text editor silently convert line endings.
- Generate the SHA-1 digest and select the Hex or Base64 representation required by the legacy system. Click the calculate button. The result appears as 40 lowercase hexadecimal characters. Toggle to Base64 when the consuming system expects the 28-character padded form. The underlying 20 digest bytes are identical either way.
- Compare every character through a trusted channel, and use SHA-256 or SHA-512 instead for new security-sensitive work. A matching digest only proves that the exact byte sequence matches. It does not prove authorship. For new designs, switch to a stronger algorithm and migrate stored references when you can.
Hex or Base64: Which Output Format Do You Need
Legacy systems usually pick one format and stick with it. Reading the wrong one will make a perfectly correct digest look like a mismatch, which is the most common reason "the hash does not match" appears on these pages. The table below summarizes the practical differences for SHA-1 specifically.
| Property | Lowercase Hex | Standard Base64 |
|---|---|---|
| Character set | 0 through 9 and a through f | A through Z, a through z, 0 through 9, +, / |
| Output length for SHA-1 | 40 characters | 28 characters (one '=' padding) |
| Typical use | Checksum files, .sha1 sidecars, README listings | API tokens, embedded references, compact fields |
| Case-sensitive? | Yes - lowercase form is the standard | Yes - case is part of the encoding |
| Encoding standard | RFC 4648 section 8 (base16) | RFC 4648 section 4 |
If the reference value on the download page is a 40-character string of digits and lowercase letters, copy the Hex result. If it is a 28-character string that ends with '=' and may contain uppercase letters or the '+' or '/' characters, copy the Base64 result. When in doubt, the format the publisher used is almost always the one you should match.
Why Exact Bytes and UTF-8 Encoding Matter
SHA-1 hashes bytes, not characters. A newline, a single space, and a missing trailing line ending are all byte-level differences, and they each produce a completely different digest. This is by design and is one of the algorithm's most useful properties: any accidental change to a file is detectable.
The same principle applies to text. When you type "café" in the text field, the tool encodes it as the UTF-8 bytes 63 61 66 C3 A9. Hashing the equivalent Latin-1 sequence 63 61 66 E9 would produce a different digest, even though the rendered text looks similar. For non-ASCII content, always confirm that the tool is hashing the bytes you actually intend, not a re-encoded copy.
A few practical consequences worth knowing:
- An empty text field is a valid message. Its well-known SHA-1 value is da39a3ee5e6b4b0d3255bfef95601890afd80709.
- Adding a trailing newline changes the digest, even though the screen looks the same.
- Re-saving a file with different line endings (CRLF versus LF) changes the digest.
- The filename, modification time, and the browser's MIME label are never part of the digest - only the file's raw bytes are hashed.
Verifying the Digest Safely Against a Trusted Source
A matching SHA-1 digest is a strong signal that the exact bytes you hashed are the exact bytes that produced the reference value. It does not protect against an attacker who has already substituted both the file and the published checksum, and it says nothing about who created the file. For both reasons, the reference value itself must arrive over a channel the attacker cannot rewrite.
Safe verification habits look like this:
- Get the published checksum from the project site, ideally over HTTPS, or from a signed manifest that you can verify independently.
- Generate the digest locally in your browser using the Sha1 Hash Generator. The bytes never leave your tab, and the digest operation runs against exactly the buffer you selected.
- Compare every character. Watch for case, leading zeros, trailing whitespace in the published string, and any extra characters pasted in by accident.
- If you control the consuming system, migrate the stored reference to SHA-256 or stronger and publish the new checksum over an authenticated channel.
Real Situations Where This Tool Solves the Problem
The most common reason people search for "get SHA-1 hash" is that some legacy artifact still expects one. A few concrete examples where the browser workflow is the right fit:
- An older download portal lists a SHA-1 next to each file. You have already downloaded the file and want to confirm it is the original without installing extra software.
- An archive catalog stored SHA-1 values years ago, and you need to check which local copy matches which entry in the catalog.
- A script or library produces or consumes SHA-1, and you want to reproduce its output for debugging without spinning up a local toolchain.
- A test fixture in an older codebase hard-codes a SHA-1 and you want to confirm that a generated file still matches it.
None of these scenarios require uploading the file. The browser-based SHA-1 digest operation runs entirely in your tab, subject to the documented 100 MB limit, so the bytes you hash never reach an external server. The 100 MB ceiling reflects the browser API used here: the selected input must be available as one byte buffer before the digest operation completes. For artifacts larger than that, switch to a trusted local operating-system tool such as sha1sum on Linux or macOS, or Get-FileHash -Algorithm SHA1 in Windows PowerShell, and confirm both the algorithm and the byte source before trusting the result.
If you're weighing options, Generate a SHA 256 Hash of a File in Your Browser covers this in detail.
If you're weighing options, Generate a SHA-512 Hash With Salt in Your Browser covers this in detail.