A SHA-1 file digest is a 160-bit fingerprint of the exact bytes that make up a file, printed as exactly 40 lowercase hexadecimal characters or as 28 standard Base64 characters including any padding. It is not encryption: nothing is decrypted and nothing is recovered from the digest later, and the same bytes always produce the same digest on any compliant implementation. To calculate the SHA-1 hash of a file you point a tool at the raw bytes of the file, not at its name or its modification time, and you receive the same twenty digest bytes every time the input bytes are identical. The browser-based Sha1 Hash Generator reads the file locally, runs the FIPS 180-4 SHA-1 operation on the byte buffer, and shows the result as both lowercase Hex and padded Base64 without sending the file to a server. The 160-bit output detects accidental transfer damage in a limited workflow, but SHA-1 is collision-broken for security, and the digest must never be treated as proof of authorship, used for signatures, certificate decisions, password storage, or adversarial file approval.
When a SHA-1 file digest is the right tool
Many older download pages, archive catalogs, and long-lived software mirrors still publish SHA-1 checksums next to their files. When you have to interact with one of those systems, the only correct algorithm to compare against is the one the publisher already wrote down. This is the realistic case where calculating the SHA-1 hash of a file is the legitimate task: you want to confirm that the bytes you downloaded match the bytes the publisher originally distributed, and the publisher only recorded a SHA-1.
SHA-1 is still useful inside that compatibility boundary because it produces a stable, fixed-length identifier that any conforming implementation agrees on, and the algorithm is small enough to run in a browser tab on the local machine. According to the NIST Secure Hash Standard (FIPS 180-4), the message digest divides the input into 512-bit blocks, updates five 32-bit state words through eighty rounds per block, and finishes at exactly 160 bits. The result is short enough to read by eye, paste into an issue tracker, or store in a flat text file, which is exactly why legacy publishers chose it.
Outside that boundary, SHA-1 should not be the algorithm you select for a new design. Treat the file digest as a checksum for accidental damage only, not as a security primitive. The page is useful when a legacy download page, archive catalog, or old integration publishes a SHA-1 checksum and you need to compare exact bytes; it is the wrong tool when you are designing the next generation of the same system.
How to calculate the SHA-1 hash of a file
- Open the Sha1 Hash Generator in your browser and switch the input control to file mode rather than text mode.
- Choose the file you want to hash from your local disk. The browser reads the file through a local API and the bytes never leave the tab; the limit is 100 MB because the input must fit in one byte buffer before the digest runs.
- Click the calculate button. The page runs the standard SHA-1 compression function over the raw bytes exactly as read; the filename, the file's modification time, and the browser's MIME label are not part of the digest.
- Read the 40-character Hex string and the 28-character Base64 string the page displays. They are two encodings of the same 20 digest bytes, so a Hex-to-Base64 conversion that disagrees with the page means you copy-pasted wrong.
- Copy the representation that matches the format the legacy system expects, then close the file picker without re-saving or re-encoding the source.
If the file you want to hash is text rather than binary, the text mode of the same tool encodes the visible string as UTF-8 before hashing. That distinction matters for accented letters, emoji, and non-Latin scripts because a single character can occupy several bytes, so two visually similar inputs can hash to two different digests. The empty input is also a valid message and yields the well-known SHA-1 value da39a3ee5e6b4b0d3255bfef95601890afd80709, but you still have to click the button: an empty field is not the same as having no result.
Hex vs Base64: which representation to copy
SHA-1 produces 20 bytes. The tool exposes those bytes in the two encodings legacy systems actually use, and you should copy whichever one the consumer expects rather than converting them yourself with a separate utility. A mismatch in format is one of the most common reasons a manual comparison fails on the first try.
| Format | Length | Character set | Where it typically appears |
|---|---|---|---|
| Lowercase Hex | 40 characters | 0-9, a-f | sha1sum command-line output, *.sha1 sidecar files, most download pages |
| Standard padded Base64 | 28 characters including padding | A-Z, a-z, 0-9, +, /, = | Legacy APIs, manifest fields, embedded configuration blobs |
Hex is the most common format for file checksums, so when a publisher drops a value next to a download link it is almost always Hex. Base64 is denser and appears in protocol payloads where compactness matters. Do not feed a Hex string into a system that expects Base64 or vice versa: the characters look different and the two strings are not interchangeable, and a leading or trailing character will silently invalidate the comparison downstream.
Matching a computed digest against a published checksum
A SHA-1 file digest only has value when you compare it with a reference that came from a channel you trust. RFC 6194 documents the security considerations that apply to SHA-1 and reminds implementers that the algorithm is not suitable for collision resistance, so the match step has to be designed around that limitation rather than around wishful thinking.
The comparison itself is simple: compare every character of the copied digest against the value you received, in order, without trimming whitespace, without normalising case, and without re-encoding the source file. A match confirms that the two byte sequences are bit-for-bit identical, which is enough to detect accidental transfer damage in a controlled mirror workflow. A non-match means the bytes are different, the encoding step changed something, or the reference was wrong; you should not retry by editing the source to "make it match".
Three habits keep the comparison honest:
- Always copy the digest through the same channel and casing the publisher used, even if the casing looks unusual compared with other sites you have used.
- Pull the reference from a second, trusted location if you can, so the publisher's web page is not the only place where the expected value lives.
- Record the digest alongside the file in your own notes so the next person has something to compare against without having to re-derive it from the original source.
When SHA-1 is the wrong choice
SHA-1 is collision-broken. Real attacks have shown that different content can be engineered to share the same SHA-1 digest under realistic conditions, which removes the algorithm from anything adversarial. The following table summarises where SHA-1 is acceptable as a legacy compatibility check, where it is harmless but pointless, and where it is actively dangerous.
| Task | Is SHA-1 acceptable? | Recommended algorithm or approach |
|---|---|---|
| Match a checksum published by a legacy download page | Yes, for compatibility only | Ask the publisher to migrate the reference to SHA-256 |
| Detect accidental corruption in a private mirror | Yes, with that scope understood | Use SHA-256 or SHA-512 for new pipelines |
| Digital signature over a document or executable | No | Use SHA-256 or stronger with a real signature scheme |
| Certificate fingerprint comparison in a trust decision | No, as a security input | Use SHA-256 fingerprints; treat SHA-1 only as a legacy hint |
| Password storage | No | Use a salted, deliberately expensive KDF: Argon2id, scrypt, or bcrypt |
| Approving files uploaded by an untrusted party | No | Use SHA-256 or stronger with an authenticated channel |
One specific case worth calling out is password hashing. A plain SHA-1 digest of a password is not a password hash. General-purpose hash algorithms are deliberately fast, so an attacker can test huge numbers of guesses per second against a leaked database. The right primitive for password storage is a salted, deliberately expensive password-hashing scheme such as Argon2id, scrypt, or bcrypt, applied inside the account system that owns the credential. The Sha1 Hash Generator never adds a salt and never derives a key, so even using it locally to "store a password" would be unsafe.
Limits, edge cases, and what to do above 100 MB
The browser API used by the page has to load the entire selected input into one byte buffer before the SHA-1 operation runs, which caps the file at 100 MB on this tool. The cap is not a streaming implementation, so multi-gigabyte disk images, long video files, or very large archives will exceed it. For larger artifacts, run a trusted local operating-system tool such as sha1sum on Linux, certutil -hashfile on Windows, or shasum on macOS, and verify which algorithm the command actually invoked and which bytes it actually read.
Several other edge cases change the digest even when the change looks invisible:
- Line endings. A file ending with a Unix newline is one byte different from the same file ending with no newline, and SHA-1 will return a different value for each. Windows CRLF endings also produce a different digest than LF endings of the same content.
- Whitespace. Trailing spaces, tabs, and a final blank line all participate in the hash; visually similar inputs can correctly produce different digests.
- Encoding. Text mode hashes UTF-8 bytes, not characters. Two strings that look the same after a toLowerCase call can still hash differently if one has a combining accent and the other has a precomposed one.
- An empty input is still a valid message, and SHA-1 returns the empty-input digest da39a3ee5e6b4b0d3255bfef95601890afd80709. There is no shortcut that lets you avoid clicking the button for that case.
If you control the consuming system, the durable answer to the file-checksum question is to migrate the stored reference to SHA-256 or SHA-512 and publish the new checksum over an authenticated channel. Until that migration lands, calculate the SHA-1 hash of a file in the smallest tool that fits, copy the Hex or Base64 representation the legacy consumer expects, and compare every character against a trusted reference without trimming or re-encoding the source.