A SHA-1 hash of a file on Linux is a 160-bit fingerprint, shown as exactly 40 lowercase hexadecimal characters or 28 standard Base64 characters, computed from the file's exact byte sequence by the SHA-1 algorithm defined in NIST FIPS 180-4. On most Linux distributions the traditional way to get one is sha1sum filename, which reads the file, runs the same digest, and prints the 40-character hex value on stdout. A browser-based tool reaches the same 160-bit value without opening a terminal: you select the file inside the page, the SHA-1 operation runs locally on the selected bytes, and the result appears in the same Hex or Base64 formats that sha1sum, shasum, or a .sha1 checksum file would use. Because SHA-1 hashes the raw bytes exactly as read, the result depends on the file contents alone, not on the filename, the modification time, or the browser's MIME label, so a match against a published checksum is a precise byte-for-byte check. This is the standard way to confirm that an ISO image, tarball, or installer downloaded onto a Linux system still matches what the publisher released.
What a SHA-1 Hash of a Linux File Looks Like
A SHA-1 digest is always 160 bits long. Once those 160 bits are encoded for display, the result is one of two fixed shapes: exactly 40 lowercase hexadecimal characters, or exactly 28 standard Base64 characters including any padding. On a Linux file the algorithm works the same way it does anywhere else: the input is split into 512-bit blocks, padded to a multiple of 512 bits, and pushed through eighty rounds of state updates defined by the SHA-1 algorithm in NIST FIPS 180-4. The 20 bytes that come out are then printed as hex or Base64.
The hex representation is what sha1sum prints by default and what most .sha1 checksum files publish. The Base64 representation is what some legacy package managers, signed manifest formats, and API integrations require. The two strings always encode the same 20 bytes, so they are not two different hashes. If you paste one string into a tool that expects the other, you will see a clean conversion rather than a match, which is exactly the behavior you want when you need to feed the digest into a specific format.
Why Use the Browser Tool Alongside sha1sum
Linux already ships sha1sum in coreutils, and it works. The browser tool is useful in three situations where the command line is not ideal:
- You are on a Linux desktop but need to share a verified digest with someone on a different operating system who needs the same string in a copyable form.
- You are auditing a download on a system where you do not have a terminal open, or where installing extra utilities is restricted by policy.
- You want a second, independent implementation to cross-check sha1sum against. If both tools return the same 40-character string, you have two attestations for the same bytes from different code paths.
Under the hood, the Sha1 Hash Generator uses the SHA-1 primitive defined by FIPS 180-4 and runs it inside the browser tab on the bytes you select. The selected file is not uploaded, so the local result is the same value that sha1sum would produce locally. Treating the browser output as a complement to sha1sum rather than a replacement keeps the workflow honest: you keep the speed of the terminal and gain an independent check when one matters.
Get the SHA-1 Hash of a File on Linux Without a Terminal
When you need a 40-character SHA-1 fingerprint and you would rather not open a shell, the browser path produces the same value as sha1sum. The steps below assume a standard Linux desktop browser such as Firefox or Chromium running under GNOME, KDE, XFCE, or another common desktop environment.
- Open the Sha1 Hash Generator page in your browser and switch to the file input mode rather than the text mode.
- Click the file selector and choose the file from your Linux filesystem. Anything under 100 MB works in one pass; anything larger needs a different approach because the entire byte buffer has to fit in memory before the digest operation completes.
- Click the calculate button. The page reads the file's bytes in the tab and runs SHA-1 on the raw bytes exactly as stored on disk, without stripping a BOM, normalizing line endings, or re-encoding anything.
- Copy the 40-character lowercase hex output, or switch the display to Base64 and copy the 28-character string if the consuming system expects that format.
- Compare the copied string character by character against the value supplied through a trusted channel, such as the publisher's release notes, a signed .sha1 file fetched over HTTPS, or a checksum printed next to the download link.
Because the digest covers the raw bytes only, the filename, the modification time, and the browser's MIME label are all irrelevant. Two copies of the same file at different paths or with different timestamps will hash to the same 40 characters, which is exactly the property you want when you are confirming that an ISO image saved into ~/Downloads/ matches the one the publisher signed.
Hex and Base64: Choosing the Right Output
Both formats encode the same 20 digest bytes, so they are not two different algorithms. Picking the wrong one for the system you are feeding the digest into is one of the most common reasons a "correct" hash appears to fail validation. The table below summarizes the practical differences.
| Property | Lowercase Hex | Standard Base64 |
|---|---|---|
| Output length | 40 characters | 28 characters, including any = padding |
| Character set | 0–9 and a–f | A–Z, a–z, 0–9, +, /, = |
| Default for sha1sum | Yes | No, requires base64 or openssl wrapping |
| Common in .sha1 checksum files | Yes | Rare |
| Best for | Manual copy and paste, log files, shell scripts | API payloads, compact storage, binary protocols |
If the value you are matching came from sha1sum, a .sha1 file, or a documentation page that prints 40 characters like da39a3ee5e6b4b0d3255bfef95601890afd80709, copy the hex form. If the value came from an API field or a manifest that accepts a shorter mixed-case string ending in =, copy the Base64 form.
Verify a Downloaded File Against a Published Checksum
Checksum matching is the most common reason to compute a SHA-1 hash on Linux in the first place. The pattern is the same whether you use sha1sum or the browser tool: produce the digest locally, then compare it character by character against a value the publisher published through a channel you trust.
For a typical Linux distribution download, the publisher posts a file such as SHA1SUMS alongside the ISO or tarball. Fetch that file over HTTPS, then compute the SHA-1 of your downloaded file. If the two strings match exactly, every byte of the file matches what the publisher hashed, so accidental transfer damage such as truncated downloads, disk corruption, or partial mirrors will change the digest. The browser tool makes the comparison easy: paste your copied hex string into the compare field, paste the trusted string, and confirm a character-by-character match rather than a fuzzy "looks similar" match.
The comparison must happen over a trusted channel. A checksum posted on the same unencrypted page that hosts the download is not a separate check, because an attacker who replaced the file could just as easily have replaced the checksum. Treat the published value as authoritative only when it came through HTTPS from the publisher's own domain, or through a signed message you can verify independently.
SHA-1 in 2026: Legacy Compatibility, Not New Security
SHA-1 has been collision-broken since 2017. Researchers have demonstrated practical chosen-prefix collisions, which means two different content payloads can be constructed to share the same SHA-1 digest under realistic conditions. The hash function is therefore no longer safe for any application where an adversary might influence the input being signed: code signing, certificate fingerprints, software update manifests, password storage, or any approval workflow that needs to resist a malicious actor.
What SHA-1 is still good for is exactly the legacy checksum workflow described above: comparing a downloaded file against a value the publisher already published. If you control the system that stores the checksums, the safer choice is to publish SHA-256 or SHA-512 instead and migrate old references over time. The SHA256 Hash Generator and Sha512 Hash Generator pages follow the same in-browser workflow for the stronger algorithms. The plain SHA-1 page should only be opened when the consuming system actually requires a SHA-1 digest.
Common Pitfalls When Hashing Files on Linux
Most failed comparisons come from a small set of input mistakes. Each one is easy to avoid once you know it exists.
- Hashing text instead of the file. If you paste the contents of a file into the text input, the digest covers only the visible characters. Hidden line endings, a missing final newline, or a BOM marker at the start of the file can change the result compared to hashing the raw file bytes.
- Trusting a checksum on the same unencrypted page as the download. An HTTPS-only channel for the checksum is the minimum bar, and even HTTPS is only as strong as the certificate authority chain behind it.
- Using SHA-1 for new security work. Signature schemes, certificate pinning, password storage, and tamper detection require SHA-256 or stronger, plus a proper construction such as HMAC for authentication or Argon2id, scrypt, or bcrypt for password storage.
- Treating SHA-1 as a password hash. A plain SHA-1 digest runs at billions of guesses per second on commodity hardware. Use a salted, deliberately slow password-hashing function instead, and let the account system handle the storage details.
- Forgetting the file size limit. The in-browser path is bounded at 100 MB because the entire byte buffer has to be loaded before the digest operation completes. For multi-gigabyte ISO images or disk images, switch to a trusted local command-line tool such as sha1sum or openssl dgst -sha1.
Each of these pitfalls is documented because the failure mode looks identical to "the hash is wrong," when in fact the input, the algorithm choice, or the comparison channel is what is wrong. Fixing those usually makes the digest match without changing the file at all.
Related reading: Generate SHA256 Hash for File and Verify Integrity.