Verify Windows Downloads with SHA-256 and PowerShell

A completed download is not proof that an installer is intact or the correct release. When a publisher provides SHA-256, Windows users can calculate the downloaded file's hash and compare it before opening the file. This does not execute the installer and normally needs no administrator access.

This Windows PowerShell guide separates integrity checks from signature verification. Do not disable Defender, SmartScreen or organizational security policies to follow it.

1. Obtain a trustworthy reference

Use the official release page reached through a verified address. Match the version, operating system, architecture and file format. An ARM64 hash cannot validate an x64 release, and a ZIP archive's hash is not the hash of an executable inside it.

Matching a file against a hash supplied by the same unknown message or website does not establish trust. An attacker able to replace both can make the comparison pass. If the publisher supplies no hash, calculating one yourself is not independent evidence of authenticity.

2. Calculate SHA-256 without opening the file

Microsoft's Get-FileHash hashes file contents. -LiteralPath avoids interpreting characters such as square brackets as wildcard patterns. Replace the sample path with your actual file.

Get-FileHash -LiteralPath 'C:\Downloads\installer.exe' -Algorithm SHA256

Read the 64-character hexadecimal Hash value, alongside the algorithm and path. A matching name or size is not a substitute. Do not upload confidential files to an online hashing site simply to perform this local check.

3. Compare automatically

Save this as verify-download-sha256.ps1. It reads the file and reports a result without installing, extracting or changing execution policy.

param(
    [Parameter(Mandatory = $true)][string]$DownloadPath,
    [Parameter(Mandatory = $true)][string]$ExpectedSha256
)

$ErrorActionPreference = 'Stop'
$expected = $ExpectedSha256.Trim()
if ($expected -notmatch '\A[0-9a-fA-F]{64}\z') {
    throw 'Expected SHA-256 must contain exactly 64 hexadecimal characters.'
}
if (-not (Test-Path -LiteralPath $DownloadPath -PathType Leaf)) {
    throw 'Download file not found.'
}
$actual = (Get-FileHash -LiteralPath $DownloadPath -Algorithm SHA256).Hash
if ($actual -ine $expected) {
    throw 'SHA-256 mismatch. Do not run or install this file.'
}
Write-Output 'SHA-256 matches the supplied reference. This is not a malware verdict.'

Supply the real path and publisher-provided hash. Replace the placeholder before running:

.\verify-download-sha256.ps1 -DownloadPath 'C:\Downloads\installer.exe' -ExpectedSha256 'PUBLISHER_SHA256_64_HEX_CHARACTERS'

If organizational policy blocks scripts, do not bypass it. Use the read-only hash command in step 2 or ask IT for an approved verification method. A match applies to the bytes read at that moment and the particular reference supplied.

4. Respond to a mismatch

1. Stop installation or execution and retain the download source information.
2. Confirm SHA-256, release version and architecture.
3. Check the download is complete and you did not select an older or renamed file.
4. If appropriate, download again from the official source and recheck.
5. If the mismatch persists, contact the publisher or IT. Never replace the expected hash with your calculated value merely to obtain a pass.

A mismatch can indicate corruption, the wrong release or modification; the comparison alone cannot identify the cause. A match does not prove the program is malware-free or free of vulnerabilities.

5. Inspect signatures where supported

Get-AuthenticodeSignature reports Windows Authenticode signature information. For a signed installer, inspect:

Get-AuthenticodeSignature -LiteralPath 'C:\Downloads\installer.exe' |
    Select-Object Status, StatusMessage,
        @{Name='Signer'; Expression={$_.SignerCertificate.Subject}}

Compare the signer with the expected publisher instead of looking only for Valid. Unsigned does not automatically mean malicious, and a valid signature is not a complete safety guarantee. Investigate unexpected or unclear results through official channels.

6. Keep a verification record

For IT deployments, record the filename, version, source URL, download date, algorithm, reference hash and outcome in the change ticket. Exclude credentials and tokens. Keep the verified artifact in a controlled location so a different file is not accidentally deployed afterward.

The workflow is straightforward: verify the source, download the correct release, compare hashes, inspect signatures where available and then follow the approved installation process. SHA-256 is useful because of a trustworthy comparison, not merely because it produces a long string.