Windows users can generate a SHA-1 hash through three built-in or browser-based paths without installing new software. The Command Prompt utility CertUtil produces a SHA-1 digest from any local file using the syntax certutil -hashfile followed by the path and the algorithm name, and PowerShell offers the more flexible Get-FileHash cmdlet that returns the same 160-bit value as an object you can pipe, compare, or export. For users who need to hash short text strings or work on a Windows machine where terminal access is restricted, a browser-based SHA-1 generator runs entirely inside the browser tab, reading either UTF-8 text or file bytes up to 100 MB and returning the digest in lowercase hexadecimal or standard padded Base64. All three methods yield the same value for the same input because SHA-1 is specified in NIST FIPS 180-4 and operates on byte sequences rather than filenames, timestamps, or MIME labels. Choosing the right path depends on whether you already have a terminal open, whether the value you need to match was published as hex or Base64, and whether the checksum comes from a legacy download page that still publishes SHA-1 alongside newer algorithms.
What a SHA-1 Digest Looks Like and Why Windows Still Uses It
SHA-1 is a cryptographic hash function defined by the NIST Secure Hash Standard. It accepts any sequence of input bytes and produces a fixed 160-bit value, displayed as exactly 40 hexadecimal characters or 28 Base64 characters including the trailing padding. Windows users still encounter SHA-1 because older software catalogs, archived distributions, firmware images, and long-running integration systems publish SHA-1 checksums alongside SHA-256 values. When a verification tool asks for "the SHA-1" and supplies a 40-character hex string, the underlying expectation is that you can reproduce that same string from the same bytes.
The digest is a function of bytes only. The filename, the modification timestamp, the Windows Explorer MIME label, and the user account all stay outside the calculation. Two files with the same bytes produce the same digest even if one was renamed yesterday and the other was copied in 2009.
Generating a SHA-1 Hash in Windows Command Prompt
Windows ships CertUtil as a certificate services utility, but it also doubles as a file hashing tool that supports several algorithms including SHA-1. This is the fastest path when you already have Command Prompt open and need a one-shot digest.
- Press Win + R, type cmd, and press Enter to open Command Prompt. On Windows 11 you can also right-click the Start button and choose Terminal for a more modern interface.
- Navigate to the folder containing the file by typing cd followed by the full path, for example cd "C:\Users\YourName\Downloads".
- Type certutil -hashfile "filename.ext" SHA1 and press Enter. Replace filename.ext with the actual file name including its extension.
- Read the second line of the output. It shows the SHA-1 digest in uppercase hexadecimal. The line above it confirms the algorithm that was applied.
- Copy the 40-character hex value and compare it character by character against the published checksum. Hex comparison is not case-sensitive.
CertUtil only accepts files, not arbitrary text. If you need to hash a short string, save it to a temporary file first or switch to PowerShell or the browser tool.
Generating a SHA-1 Hash in PowerShell on Windows
PowerShell's Get-FileHash cmdlet is the more flexible built-in option. It supports SHA-1, SHA-256, SHA-384, and SHA-512, and it returns a structured object with Hash, Algorithm, and Path properties that you can pipe into other commands.
- Open PowerShell from the Start menu, or press Win + X and choose Windows PowerShell (or Terminal on Windows 11).
- Type Get-FileHash -Path "C:\Users\YourName\Downloads\filename.ext" -Algorithm SHA1 and press Enter.
- Read the Hash column. The output is uppercase hexadecimal by default. You can convert it to lowercase with .ToLower() if the comparison expects that format.
- To compare the value programmatically, store the digest in a variable and use the -eq operator: $published = "DA39A3EE..."; (Get-FileHash ...).Hash -eq $published returns True only when every character matches.
- To hash an inline string without saving a file, use the .NET method: $bytes = [System.Text.Encoding]::UTF8.GetBytes("your text"); $sha1 = [System.Security.Cryptography.SHA1]::Create().ComputeHash($bytes); [BitConverter]::ToString($sha1) -replace "-","" gives the 40-character digest.
Get-FileHash treats paths with spaces correctly when wrapped in quotes, and it accepts pipeline input, so you can hash many files in a folder with a single Get-ChildItem | Get-FileHash command.
Hashing Text or Files with a Browser Tool on Windows
When terminal access is restricted, when you need to hash a short string without saving a temporary file, or when the published checksum was given as Base64 instead of hex, a browser-based tool is often the fastest Windows-friendly option. The Sha1 Hash Generator runs entirely in the browser tab. It accepts either a UTF-8 text string or a local file up to 100 MB and returns the same 20-byte digest encoded as lowercase hex or standard padded Base64.
The tool does not upload the file or the text. The browser reads the selected bytes locally, applies the SHA-1 algorithm defined by FIPS 180-4, and displays the result. This makes it safe to use on files that contain sensitive configuration, license keys, or personal data, because the bytes never leave the machine.
Text mode matters for accented letters, emoji, and non-Latin scripts because each character can occupy multiple UTF-8 bytes. File mode hashes raw bytes exactly as the operating system reads them, so the filename, modification time, and Windows MIME label are excluded from the digest.
Verifying a Downloaded Windows File Against Its Published SHA-1
The most common reason to generate a SHA-1 hash on Windows is to confirm that a downloaded file arrived intact. Many legacy archive pages, firmware repositories, and software mirrors still publish a SHA-1 string alongside the download link, and the workflow below covers that scenario end to end. For a deeper look at legacy checksum verification, see Generate a SHA-1 Hash for Legacy Checksums in Your Browser.
- After downloading the file, open the page that lists the published checksum and locate the line that begins with the file name or a SHA-1 label. Copy the 40-character hex value to the clipboard.
- Open Command Prompt, navigate to the download folder, and run certutil -hashfile "filename.ext" SHA1. Replace filename.ext with the downloaded file's actual name.
- Read the second line of the output, which contains the uppercase hex digest.
- Compare the two values visually or with a tool that highlights differences. A match means the file's bytes are identical to what the publisher hashed. A mismatch means the download was truncated, corrupted, or substituted.
- If the page publishes the checksum as Base64, switch to a method that returns Base64 output or convert the hex digest with an encoding tool.
Comparison must be character-by-character and must not normalize whitespace. A space, a hyphen, or a missing character means the file does not match.
Why Windows Line Endings, BOM, and Trailing Whitespace Change the Digest
Several Windows-specific behaviors can produce surprising digests that still look correct in isolation.
Line endings
Notepad writes Windows files with CRLF line endings, while many Unix-origin tools expect LF only. Even a single line ending difference changes the byte sequence and therefore the SHA-1. When comparing hashes against a published value, hash the bytes exactly as they were when you received them.
BOM
Some Windows editors save UTF-8 files with a byte-order mark, three bytes EF BB BF. The BOM is part of the file and is included in the digest. If the publisher hashed the file without a BOM, your hash will not match even though the visible text is identical.
Trailing newlines and spaces
Notepad and many Windows tools add a final newline that is invisible in the editor. A 32-character password and the same 32-character password followed by Enter produce different digests. Empty input is also a valid message: the SHA-1 of an empty text field is the well-known value da39a3ee5e6b4b0d3255bfef95601890afd80709.
Case
SHA-1 produces lowercase bytes internally, but Windows tools often display the digest in uppercase. The two representations describe the same value, but a literal string comparison will fail until you normalize case.
When You Should Switch From SHA-1 to SHA-256 on Windows
SHA-1 is collision-broken. Researchers have demonstrated practical attacks that construct different content with the same digest, and RFC 6194 documents the security considerations in detail. This means a SHA-1 match should not be treated as proof of authorship, as a signal that a certificate is trustworthy, as a password verification mechanism, or as tamper protection for any adversarial workflow.
A SHA-1 match remains useful for one narrow purpose: detecting accidental transfer damage in a workflow where both sides use the same byte sequence and the threat model is corruption, not substitution. This covers most legacy checksum use cases.
If you control the system that publishes or stores the checksum, migrate the reference value to SHA-256 or stronger and publish the new checksum over an authenticated channel. The SHA256 Hash Generator produces the same browser-local workflow with a 256-bit digest. For password storage, use a salted, deliberately expensive scheme such as Argon2id, scrypt, or bcrypt, implemented by the account system rather than by a general-purpose hashing tool.
| Method on Windows | Input type | Output format | Needs terminal | Install required |
|---|---|---|---|---|
| CertUtil (CMD) | Local file only | Uppercase hex | Yes | No |
| Get-FileHash (PowerShell) | Local file or piped bytes | Uppercase hex | Yes | No |
| Browser-based SHA-1 tool | UTF-8 text or local file up to 100 MB | Lowercase hex or padded Base64 | No | No |
The output sizes are identical across all three methods because SHA-1 always produces a 160-bit digest. The format choices, hex versus Base64 and uppercase versus lowercase, only affect how the digest is displayed and must match what the receiving system expects.
Related reading: Generate a SHA256 Hash Locally as Hex or Base64.