Use 7-Zip to Check SHA-256 Hashes on Windows

That distinction matters when downloading large Windows ISOs, utilities from smaller vendors, portable apps, drivers, or archives mirrored across multiple servers. Used correctly, 7-Zip’s hashing feature can catch incomplete downloads, file corruption, and substitutions that do not match the publisher’s stated digest. Used casually, it can create false confidence—particularly if the file and its supposedly authoritative checksum came from the same compromised place.

What 7-Zip’s hash feature actually does​

A cryptographic hash function converts a file of any size into a fixed-length value. With SHA-256, even a tiny change to the underlying file produces a dramatically different result. That makes the hash useful as a fingerprint for a specific byte-for-byte file.

7-Zip documents hash calculation for several methods, including CRC32, CRC64, SHA-1, SHA-256, and BLAKE2sp. For modern download verification, SHA-256 is the sensible default when a publisher offers it. Microsoft recommends SHA-256 for Authenticode-related use and warns against relying on SHA-1 alone for new code-signing releases. SHA-1 may still appear in older download instructions and can reveal whether two files differ, but it should not be presented as equivalent to SHA-256 for current security decisions.

The key limitation is simple: 7-Zip calculates a value for the file you selected. It does not independently discover the publisher’s expected value, establish who published that value, or automatically decide that the two match. You must obtain the expected SHA-256 digest and compare it carefully with 7-Zip’s output.

A matching result means the downloaded file matches the reference digest. SHA-256 is designed to make it infeasible to substitute a different file while retaining the same digest for that specified file. A mismatch means something is wrong: the download may be incomplete, damaged, the wrong version, or different from the file the publisher described. Do not run the file until the discrepancy is resolved.

Finding SHA-256 in 7-Zip from File Explorer​

The Explorer route depends on installing the GUI edition of 7-Zip and enabling its shell-context-menu integration. If that integration is not installed or has been disabled, the relevant menu item will not appear. The menu’s exact placement also varies with the 7-Zip release, configuration, and the Windows context-menu implementation.

A commonly documented route is to select the file in File Explorer, use Shift+right-click, and then look for the 7-Zip entry and its CRC-SHA submenu. From there, select SHA-256.

On some Windows 11 configurations, 7-Zip options may be located outside the compact initial context menu. In that case, Windows may require an extra action to reveal additional choices. That is not a universal path, however, so it is better to search for the 7-Zip and CRC-SHA entries than to assume every PC will show the same sequence.

If no 7-Zip option appears:

1. Confirm that the graphical 7-Zip application, not only a command-line component, is installed.
2. Open 7-Zip’s settings and check whether Explorer or shell-context-menu integration is enabled.
3. Close and reopen File Explorer if a setting has just changed.
4. Use the command-line method below if the context menu remains unavailable or if you prefer a repeatable process.

The interface may offer several hash types. Select SHA-256 only when the publisher provides a SHA-256 value to compare. A SHA-256 digest cannot be compared with a SHA-1, CRC32, or BLAKE2sp value; both sides must use the same algorithm.

The comparison step is where verification happens​

Before calculating anything, find the expected digest for the exact release you downloaded. Check the product version, edition, architecture, language, and filename. A vendor may publish separate values for x64 and Arm builds, installers and ZIP packages, or different monthly ISO revisions. Comparing against a checksum for a nearby but different download will correctly produce a mismatch.

After 7-Zip calculates the SHA-256 value, compare the full string against the reference value. Do not rely on the first few characters. The values must match completely, with no changed, missing, or extra character. SHA-256 values are normally written as hexadecimal text, so capitalization is generally not the meaningful difference; the sequence of digits and letters is.

A match supports a precise conclusion: your file is the same as the file represented by that reference digest. It does not independently prove that the reference was supplied by the real publisher.

That may sound like a technicality, but it describes a realistic failure mode. If an attacker can replace a download on a website and alter the checksum displayed next to it, they can publish a malicious file together with the matching hash for that malicious file. 7-Zip will calculate the altered file’s hash accurately, and the comparison will still pass. The weak point in that scenario is not SHA-256; it is the trustworthiness of the reference checksum.

For higher confidence, obtain the digest through a separate trustworthy channel where possible. A publisher’s signed release manifest, an established release announcement mirrored independently, or an authenticated vendor distribution channel provides a stronger basis than a checksum placed only beside the download on a page that could have been altered. The best available method depends on what the publisher provides, but the general principle is to avoid having one potentially compromised location supply both the file and the proof used to validate it.

A reliable fallback: 7-Zip at the command line​

7-Zip documents the hash-command syntax as:

7z h -scrcsha256 a.iso

That short form works only when PowerShell can locate 7z. On a typical Windows installation, 7-Zip may not be on the PATH, so supplying only the downloaded file’s full path does not solve that problem. Call the executable by its installation path instead. For a common installation location, use:

& "C:\Program Files\7-Zip\7z.exe" h -scrcsha256 "C:\Users\YourName\Downloads\example.iso"

The 7-Zip program path can differ if it was installed elsewhere, so adjust the first quoted path as needed. Another option is to change into the folder containing 7z.exe and explicitly run that executable:

Set-Location "C:\Program Files\7-Zip"
.\7z.exe h -scrcsha256 "C:\Users\YourName\Downloads\example.iso"

This approach is especially helpful when Explorer integration is missing, when checking several files in a controlled workflow, or when you want a command that can be recorded accurately in support documentation. As with the context-menu route, the command only calculates the digest. You still need to compare that output with the expected SHA-256 value yourself.

For a high-stakes download, preserve enough context to repeat the check later: retain the original filename, version information, and the source of the expected digest. Avoid renaming files in a way that obscures which published checksum was intended for them.

Hash verification and publisher identity are different checks​

A checksum comparison answers, “Does this file match the stated file?” It does not by itself answer, “Who created it?” Windows digital signatures address a related but different question for file types that support Authenticode signing.

Microsoft describes a valid Windows digital signature as depending on both integrity and trust: the file’s hash must match the signed value, and the publisher and certificate authority must be trusted. That gives signature validation an identity component that a bare SHA-256 string lacks.

For a supported file type, PowerShell can retrieve Authenticode signature information with:

Get-AuthenticodeSignature -FilePath "C:\Users\YourName\Downloads\setup.exe"

To focus on signatures Windows reports as valid, use:

Get-AuthenticodeSignature -FilePath "C:\Users\YourName\Downloads\setup.exe" |
    Where-Object Status -eq Valid

This is a supplement, not a replacement for a publisher checksum. An ISO or archive may not have the sort of embedded Authenticode signature PowerShell can validate in this way, while an executable may have a valid signature but still not be the specific version you intended to download. In the other direction, a SHA-256 match can confirm the exact expected bytes but cannot establish the publisher’s identity unless the reference digest itself came from a trustworthy source.

Nor does a valid signature guarantee that software is harmless, appropriate for your environment, or free of defects. It means Windows was able to validate the signature under its trust policy; it is not an all-purpose safety assessment.

A practical workflow for downloads​

For most Windows users, a proportionate workflow looks like this:

1. Download from the vendor or project’s legitimate distribution channel.
2. Locate the SHA-256 value for the exact file and version.
3. Prefer obtaining or corroborating that value through a separate trusted channel when the download is important or the risk is high.
4. Use 7-Zip’s CRC-SHA menu or its hash command to calculate the local file’s digest. In PowerShell, invoke 7z.exe by its installation path if 7-Zip is not on the PATH.
5. Compare the entire SHA-256 value. Delete and re-download on any mismatch.
6. For supported executables and similar signed files, inspect the Authenticode signature as an additional Windows-native check.
7. Treat unexpected prompts, an unfamiliar signer, a confusing version mismatch, or an absent checksum as reasons to pause rather than reasons to proceed.

The value of 7-Zip here is convenience: a familiar Windows archive tool can perform an important integrity check without another utility. The security value comes from using that convenience with the right mental model. A hash is excellent evidence that two byte sequences are the same. It becomes evidence of an authentic download only when the expected hash is anchored to a source worthy of trust.

When this feature is most useful​

The feature is particularly worthwhile for large downloads where accidental corruption is plausible, including ISO images and archives. It is also useful when a publisher explicitly provides a SHA-256 checksum and expects customers to verify it before installation. In these situations, a mismatch gives a clear, actionable result: do not use that file.

It is less decisive when a site publishes no checksum, publishes only legacy SHA-1 values, or places the file and its hash in the same uncorroborated location. You can still calculate a hash for recordkeeping or compare copies obtained from different sources, but do not turn that into a claim of publisher authentication.

7-Zip’s hidden-in-plain-sight hash command is therefore best seen as a practical integrity tool, not a one-click security verdict. Knowing that boundary makes the feature more useful, not less: it tells you exactly what a successful result proves, what it cannot prove, and when a second check—such as Windows signature validation or an independently trusted release record—is warranted.