A SHA-1 file hash is the 160-bit message digest of the exact bytes that make up a file, displayed as a 40-character lowercase hexadecimal string or a 28-character standard padded Base64 string. To get the SHA-1 hash of a file, you select the file through a browser-based digest tool, the tool reads the bytes locally, and the result appears in both encodings for comparison against a checksum you already trust. The hash is deterministic: the same bytes always produce the same 40 hex characters, and any change to a single byte inside the file produces a completely different digest. SHA-1 is defined by NIST's Secure Hash Standard (FIPS 180-4) and pads the input, splits it into 512-bit blocks, and updates five 32-bit state words across eighty rounds per block, yielding a final 160-bit state. A file-mode hash treats the bytes exactly as the file system delivered them — line endings, spaces and a final newline all participate — so the result is sensitive to the precise byte sequence, not to a normalized view of the content.
What the SHA-1 Hash of a File Actually Represents
A SHA-1 digest is always 160 bits long. Expressed as lowercase hexadecimal, that is exactly 40 characters, since each hex digit encodes 4 bits and 40 × 4 = 160. Expressed as standard Base64 per RFC 4648, the same 20 bytes occupy 28 characters including the single '=' padding character that completes the final group. There is no shorter valid form and no longer valid form — a 39-character or 41-character string is either truncated or padded with invalid bytes. The hash function processes input bytes through padding, block-splitting, and 80 rounds of state updates, producing a fixed-length output that depends on every bit of the input.
The digest is a one-way function. You cannot recover the original file from its hash, and there is no key, salt, or other secret involved. Two different files can collide — produce the same SHA-1 digest — and this property has been demonstrated in practice under controlled conditions, which is why the algorithm is no longer appropriate for new security designs. For an integrity check where you only compare against a single checksum that came through a separate trusted channel, the function still does its job: it reliably detects any byte change in the file.
File Mode vs Text Mode: Pick the Right Input
When you get a SHA-1 hash from a tool that accepts both text and file inputs, the two modes are not interchangeable. Text mode encodes the visible string as UTF-8 before hashing, which means an accented character like "é" expands to two bytes (0xC3 0xA9) and a single emoji can expand to four bytes or more. The same word pasted into the text box and the same word read from a file can therefore produce different digests if the file was saved in a non-UTF-8 encoding or contains a byte-order mark.
File mode hashes the raw bytes exactly as the file system delivers them. The filename, modification timestamp, and the MIME label supplied by the browser are not part of the digest. For any downloaded file, archive, installer, or disk image that came with a published SHA-1 checksum, file mode is the correct choice. Text mode is appropriate when you are reproducing a checksum that was clearly generated from a UTF-8 string — for example, a password-like passphrase, a canonical license notice, or a short configuration token.
Get the SHA-1 Hash of a File in Five Steps
- Open the Sha1 Hash Generator in a modern browser. The tool runs entirely in the tab; nothing is uploaded.
- Choose the file input option rather than the text box. If the file is larger than 100 MB, switch to a local operating-system utility, because the browser-based path needs the full byte buffer available before the digest operation completes.
- Select the file from your local storage. The browser reads it into memory, runs the SHA-1 digest defined by FIPS 180-4, and discards the reference once the hash is computed.
- Click the button to calculate the SHA-1 digest. The result appears in two formats: a 40-character lowercase hex string and a 28-character padded Base64 string.
- Copy the format that the legacy system expects — hex for nearly all checksum pages and README files, Base64 for some older APIs — and paste it next to the value you were given, comparing every character through a trusted channel.
The empty file is a valid input and has the well-known SHA-1 value da39a3ee5e6b4b0d3255bfef95601890afd80709. This is the same 40-hex-character digest you will see if you point the tool at a zero-byte file, and it is a useful sanity check that the tool is wired up correctly. An empty field in text mode returns the same value; "no result" only appears when you do not click the button at all.
Reading Hex and Base64 Without Trimming or Re-encoding
The 40-hex-character output uses only the characters 0–9 and a–f in lowercase. Some systems publish checksums in uppercase; both are valid representations of the same digest bytes and the comparison should be case-insensitive at the character level after normalization. The 28-character Base64 output uses the standard RFC 4648 alphabet (A–Z, a–z, 0–9, +, /) with a single '=' padding character at the end. Hex and Base64 are encodings of the same 20 bytes — they are not two different hash algorithms, and you should never publish both expecting them to act as independent checksums.
When you copy the digest into another tool, resist the temptation to trim whitespace, convert line endings, or apply any text transformation. A single missing leading zero or an accidental space inside the string produces a comparison failure that has nothing to do with the underlying file. If the published value includes spaces, colons, or line breaks between groups — a common style in README files — strip those presentation characters before comparing, but leave the actual hex or Base64 content untouched.
Why Your Hash Doesn't Match the Published Checksum
Most "wrong hash" outcomes come from one of three root causes, and a careful check usually pinpoints which one is in play.
- Wrong input mode. Pasting the contents of a file into a text box and comparing against a file-mode digest will fail if text mode applied UTF-8 normalization, dropped a trailing newline, or treated CRLF line endings differently from LF.
- Incomplete or corrupted download. The file you hashed is not the file the publisher checksummed. Re-download and compare again — a single byte difference in a multi-gigabyte file is enough to invalidate the entire digest.
- Re-encoded source. A "view source" copy of an HTML page, a clipboard paste through a system that converts encoding, or a copy from a viewer that stripped a byte-order mark will all change the byte sequence and the resulting hash.
Beyond those three, very large files occasionally trigger a memory or browser-API limitation. The 100 MB cap on the local buffer is a practical boundary, not an arbitrary one, and files larger than that need a streaming command-line tool that reads and digests in chunks. For files smaller than the limit, a second calculation with the same file usually confirms whether the published value or your environment is at fault.
When SHA-1 Is and Isn't the Right Tool
SHA-1 is acceptable in narrow, well-understood workflows: verifying a download against a checksum that came through a separate authenticated channel, matching an archive entry against a catalog entry, or reproducing a legacy integration that still requires the older algorithm. In each of these cases, the use is comparison-only, the channel is trusted, and there is no adversarial pressure to produce a colliding file.
SHA-1 is not appropriate when the use case is adversarial or security-critical. Per the security considerations in RFC 6194, collision attacks against SHA-1 are practical and have been demonstrated. Do not use SHA-1 for digital signatures, certificate fingerprint comparisons where the certificate authority is not also out-of-band verified, code-signing decisions, password storage, or any workflow where an attacker could substitute a colliding payload. A plain SHA-1 digest is also not a password hash — fast general-purpose algorithms let an attacker test billions of guesses per second. Password storage requires a salted, deliberately slow scheme such as Argon2id, scrypt, or bcrypt, implemented by the account system itself.
For any new system that is allowed to choose its own digest, prefer SHA-256 or SHA-512. The 256-bit variant produces 64 hex characters or 44 Base64 characters including padding, and the 512-bit variant produces 128 hex characters or 88 Base64 characters including padding. Both remain collision-resistant against current public cryptanalysis and are widely supported. If you are migrating an existing verification flow, the SHA-512 verification guide walks through the same character-by-character comparison at a higher security level. Update the stored reference to a stronger algorithm whenever the consuming system can be changed, and publish the new checksum over an authenticated channel.
SHA-1, SHA-256, and SHA-512 for File Digests Compared
The three algorithms share the same interface — arbitrary input, fixed-length output — but differ in output size, hex and Base64 length, and security posture. The table summarizes the exact values defined by their respective NIST standards.
| Property | SHA-1 | SHA-256 | SHA-512 |
|---|---|---|---|
| Output size (bits) | 160 | 256 | 512 |
| Hex character length | 40 | 64 | 128 |
| Base64 character length (with padding) | 28 | 44 | 88 |
| Block size (bits) | 512 | 512 | 1024 |
| Collision status | Broken in practice | Resistant | Resistant |
| Recommended use | Legacy checksum comparison | New file integrity, signatures | High-assurance integrity, signatures |
For a checksum page you cannot change, SHA-1 is what you have to live with. For any system you control, switch to SHA-256 or SHA-512 and update the published reference at the same time, then re-verify the migration by comparing the new digest against the file once more.
If you're weighing options, Generate a SHA 256 Hash of a String the Right Way covers this in detail.