A SHA-1 file hash is the 160-bit message digest defined by NIST FIPS 180-4, rendered for display as exactly 40 lowercase hexadecimal characters or 28 padded Base64 characters. When you search for a way to "get sha1 hash of file cmd," the goal is almost always one of two things: match a checksum published next to a download so you can confirm the bytes arrived intact, or generate a value to share alongside a file so a recipient can repeat the same check. Windows ships certutil -hashfile and the PowerShell Get-FileHash cmdlet, while Linux and macOS include sha1sum and shasum, and any of these will produce the same digest from a command line on a local machine. The same SHA-1 value can be produced entirely in a browser tab using the Sha1 Hash Generator, without installing software and without uploading the file to a remote server. This guide focuses on the browser workflow that maps directly onto the CMD task: choose the right input mode, generate the digest, and compare every character against the published checksum.
Why a Browser Tool Replaces CertUtil and Get-FileHash
The command-line approach is fast and built into every modern operating system, but it has practical limits. The target file must live on a machine where you can open a shell, the terminal must accept long paths, and you need to remember the exact flag (SHA1, SHA1sum, or -Algorithm SHA1 depending on the tool). A browser-based utility sidesteps the install step, works on any device that can open a webpage — a locked-down workstation, a borrowed laptop, even a phone — and produces an identical 40-character hex string once you select the same file. The internal mechanism is the same: the browser's SHA-1 digest function defined by FIPS 180-4 processes the file bytes through the standard padding, 512-bit block, and 80-round schedule, then returns the same 20 digest bytes.
If you specifically want to stay inside CMD, the native options are:
- Windows: certutil -hashfile "C:\path\to\file.zip" SHA1 or Get-FileHash -Algorithm SHA1 "C:\path\to\file.zip" in PowerShell.
- Linux: sha1sum /path/to/file.zip.
- macOS: shasum -a 1 /path/to/file.zip.
Each of these prints a single line of 40 hex characters. When shell access is unavailable — or you simply want a result that is easier to copy, paste, and visually compare — the browser alternative gives you the same string with a few clicks.
Get the SHA-1 Hash of a File in Your Browser
For readers who would rather skip the terminal, here is the direct browser workflow that produces the same 40-character string a CMD tool would.
- Open the Sha1 Hash Generator in a desktop or mobile browser. No installation, account, or plugin is required.
- Switch the input mode to file. The page offers a text field and a file picker; choose file mode so the tool hashes the raw bytes of the selected document rather than the characters you type.
- Select the file you want to hash. Files up to 100 MB are supported; the selected bytes are read locally and never sent to a server.
- Click the button that generates the digest. The page runs the SHA-1 algorithm defined in FIPS 180-4 over the file bytes and produces the same 160 bits every compliant implementation produces.
- Choose the output representation required by your target system. Use lowercase hexadecimal for the common certutil / sha1sum style checksum, or standard padded Base64 when the legacy system expects the 28-character encoded form.
- Copy the result and paste it next to the published checksum. Compare every one of the 40 hex characters or 28 Base64 characters in order; a single mismatch means the bytes you have are not the bytes the publisher signed.
- For artifacts above the limit, fall back to a trusted local operating-system tool and confirm which algorithm and byte sequence it received before treating the value as authoritative.
Hex and Base64: Two Views of the Same 20 Bytes
The digest itself is always 20 bytes. Hex and Base64 are just two encodings of that identical sequence, and the Sha1 Hash Generator lets you pick whichever representation the receiving system expects. Hex is the default for almost every command-line tool: certutil, sha1sum, and Get-FileHash all print lowercase hex with 40 characters. Base64 shows up in some older database exports, certificate blob fields, and a handful of web APIs.
| Property | Hex output | Base64 output |
|---|---|---|
| Length | Exactly 40 characters | Exactly 28 characters including padding |
| Alphabet | 0–9 and a–f | A–Z, a–z, 0–9, +, /, with = padding |
| Used by | certutil, sha1sum, Get-FileHash | Legacy certificate blobs, some REST APIs |
| Case-sensitive when comparing | Yes | Yes |
| Same underlying digest | Yes — both encode the same 20 bytes | Yes — both encode the same 20 bytes |
If the system you are feeding expects a 40-character lowercase string with no spaces, choose Hex. If it expects a single line of A–Za–z0–9+/= ending in one or two = characters, choose Base64. Never trim whitespace, never reformat the spacing, and never convert between the two by hand — both modes of the tool emit the canonical RFC 4648 form, so the bytes themselves stay exact.
What the File Mode Includes — and What It Leaves Out
The file workflow hashes the document's raw bytes exactly as the operating system hands them to the browser. That means the SHA-1 of the same content is reproducible across CMD, Linux, and the browser, as long as every tool sees the same byte sequence. Three things are deliberately outside the digest:
- The filename. Renaming release.zip to release-final.zip produces the same hash.
- The modification time. A file copied to a new location carries the same digest.
- The MIME label assigned by the browser. The browser may announce application/zip, but that string is not included in the bytes the digest sees.
Text mode behaves differently. When you type characters into the text field, the tool encodes the visible string as UTF-8 before hashing, which matters for accented letters, emoji, and non-Latin scripts because a single character can occupy multiple bytes. The two modes are not interchangeable: hashing the bytes of a .txt file is not the same as hashing the text the file contains if the file was saved in a different encoding. If your CMD workflow operates on bytes, keep the browser tool in file mode.
One byte-level detail is worth noting: the empty string is a valid SHA-1 input with a fixed, well-known digest (da39a3ee5e6b4b0d3255bfef95601890afd80709). An empty text field is not the same as clicking the button with no input at all — the page only displays a digest once it has run the algorithm on something.
Where SHA-1 Still Fits, and Where It Must Not
The honest framing matters. SHA-1 is collision-broken: research has shown that attackers can construct different content with the same digest under realistic conditions. That disqualifies the algorithm for any new security design, including digital signatures, certificate fingerprints used for trust decisions, password storage, adversarial file approval, and tamper protection. The NIST standard FIPS 180-4 and RFC 6194 spell out the algorithm and the security considerations.
Where SHA-1 still earns its place:
- Matching a legacy checksum printed next to a software download, ISO image, or firmware blob. The publisher encoded it once; you only need to detect accidental transfer damage.
- Feeding historical data systems that have not yet migrated to SHA-256 or SHA-512.
- Comparing byte-for-byte equality with a value already on file for compatibility reasons.
Where it must not be used:
- Signing new artifacts.
- Verifying a file's authorship or origin beyond detecting a transfer error.
- Storing passwords. SHA-1 is a fast general-purpose algorithm; attackers can test billions of guesses per second against it. Password storage requires a salted, deliberately expensive scheme such as Argon2id, scrypt, or bcrypt, implemented by the account system, not by a checksum page.
- Building approval workflows that decide whether an upload is safe.
A useful habit is to repeat every CMD-style checksum comparison character by character against a value delivered through a different channel than the file itself. For the same workflow applied to a stronger algorithm or with full step-by-step comparison notes, the SHA-1 file-hash comparison walkthrough lays out the matching procedure in detail. If you control the receiving system, migrate the stored reference to SHA-256 or stronger and publish the new checksum over an authenticated channel.
Limits of the Browser File Mode
The 100 MB cap reflects the underlying browser API rather than the algorithm — the entire selected buffer must be readable in memory before the digest function can consume it. For typical downloads, ISO images under that size, firmware blobs, and document archives, this is plenty. For multi-gigabyte disk images, operating-system installers, or compressed backups, switch back to a trusted local command-line tool:
- Windows: certutil -hashfile bigfile.bin SHA1.
- Linux: sha1sum bigfile.bin.
- macOS: shasum -a 1 bigfile.bin.
Before trusting any large-file digest, verify which algorithm the tool ran and which bytes it read. SHA-1 and SHA-256 share the same prefix letter but produce completely different output lengths, and an accidental -Algorithm SHA256 argument inside a SHA-1 workflow is a common silent-mismatch cause. Always record both the algorithm name and the expected digest in your notes, and never assume a match based on the prefix alone.
For a deeper look, see Generate SHA256 Hash and Match It to a Reference.