How to Check Whether an Officially Distributed File Has Been Modified by Comparing Hash Values

Why File Integrity Verification Matters More Than You Think

A matching hash means that the file on your device has the same contents as the file used to produce the published checksum. A mismatch means the two files are not identical, so you should not open, install, flash, or execute the downloaded file.

However, a matching hash does not automatically prove that the file is genuine. The result is only trustworthy when the expected hash comes from a reliable official source. If an attacker can replace both the download and the checksum displayed beside it, the two values may still match.

For operating system images, firmware, software installers, security tools, and other sensitive downloads, verify both the file and the source of the reference checksum before using it.

Verify the Checksum Source Before Checking the File

Start by locating the expected hash on the developer’s official download page, release repository, security bulletin, or signed checksum file. Do not rely on a hash copied into a forum post, unofficial tutorial, download aggregator, or mirror description unless the publisher specifically identifies it as an authorized source.

Whenever possible, obtain the file and the checksum through separate trusted paths. For example, you might download an ISO from an authorized mirror but obtain its SHA-256 value from the developer’s HTTPS website. This reduces the chance that a compromised mirror can replace both items.

Also confirm that the checksum belongs to the exact file you downloaded. Releases may include separate hashes for different architectures, languages, editions, package formats, or version numbers. A checksum for an ARM image will not match the x86 image, and a hash for a compressed archive will not match the extracted file inside it.

Check these details before calculating anything:

• Exact filename and version
• Operating system or device model
• Architecture, such as x64, ARM64, or ARM
• File format, such as .iso, .zip, .exe, or .bin
• Hash algorithm and encoding used by the publisher

Most published checksums are hexadecimal strings, but some projects use formats such as Base64. Two hashes generated from the same file will not appear identical when they are represented in different encodings, so compare like with like.

If the publisher provides a digital signature such as a .sig or .asc file, use it in addition to the checksum when practical. A checksum helps confirm that the file has not changed relative to a reference value. A properly verified digital signature can also help establish that the reference was signed by the expected publisher.

Generate and Compare the SHA-256 Hash

Use the same algorithm listed by the publisher. When SHA-256 is available, it is generally preferable to legacy MD5 or SHA-1 checksums.

Suppose the downloaded file is named product-update.iso. Use the command for your operating system.

Operating system	SHA-256 command
Windows PowerShell	Get-FileHash ".\product-update.iso" -Algorithm SHA256
Windows Command Prompt	certutil -hashfile "product-update.iso" SHA256
macOS	shasum -a 256 "product-update.iso"
Linux	sha256sum "product-update.iso"

Quotation marks are useful when the filename or folder path contains spaces. You can also provide the full path rather than moving into the download directory first.

The command will produce a string similar to this:

9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Compare the entire generated value with the entire official value. Do not check only the beginning and end. A partial visual match does not establish that the complete checksum is identical.

Uppercase and lowercase hexadecimal letters are equivalent, so these represent the same value:

ABCDEF1234

abcdef1234

Spaces, labels, filenames, or line endings surrounding the hash should not be treated as part of the checksum itself. The meaningful portion is the complete sequence of hash characters.

For a safer comparison in PowerShell, you can store the official value and compare it programmatically:

$expected = "PASTE_THE_OFFICIAL_SHA256_HERE"
$actual = (Get-FileHash ".\product-update.iso" -Algorithm SHA256).Hash

if ($actual -ieq $expected.Trim()) {
    "MATCH: The file contents match the published checksum."
} else {
    "MISMATCH: Do not use this file."
}

The -ieq comparison ignores letter case but still requires the complete values to match.

On Linux, publishers may provide a checksum file containing both the hash and filename, for example:

9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08  product-update.iso

When that file is trusted and formatted correctly, verification can often be performed automatically:

sha256sum --check product-update.iso.sha256

A successful result normally displays the filename followed by OK. Make sure the checksum file itself came from the official source; automatic checking does not make an untrusted reference trustworthy.

Avoid uploading confidential, proprietary, or unreleased files to online hash calculators. A local command-line tool calculates the checksum without sending the file to another service and normally requires no additional installation.

Decide What the Result Means and What to Do Next

A matching hash supports one specific conclusion: the downloaded file is byte-for-byte consistent with the file represented by the trusted checksum.

It does not prove that the software is safe, free from vulnerabilities, or suitable for your device. It also does not prove publisher identity when the checksum came from the same potentially compromised location as the file. For higher-risk downloads, check the publisher’s digital signature, signing certificate, release announcement, or package-manager verification as well.

A mismatch means the downloaded bytes differ from the reference. Common causes include an incomplete transfer, corruption during storage or copying, selecting the wrong edition, hashing the extracted file instead of the original archive, or using the wrong algorithm. Malicious modification is also possible, but a mismatch by itself does not reveal the cause.

When the values do not match:

1. Do not run, mount, install, extract, or flash the file.
2. Confirm that you used the correct algorithm and exact release file.
3. Delete or quarantine the mismatched copy.
4. Download it again from the publisher or another authorized mirror.
5. Obtain the expected checksum again from the official source.
6. Recalculate and compare the complete values.
7. If repeated official downloads still fail, stop and report the issue to the publisher.

Do not treat repeated mismatches as something to bypass, particularly with executable installers, operating system images, router firmware, BIOS updates, wallet software, or security utilities. Installing the wrong or corrupted firmware can make a device unusable, while a modified executable can compromise the system before the user notices any visible problem.

MD5 or SHA-1 may still detect accidental corruption when they are the only values supplied for an older release. They should not provide the same confidence against deliberate manipulation as a modern SHA-256 checksum or a properly verified digital signature. Do not convert an MD5 or SHA-1 value into SHA-256; instead, generate the algorithm the publisher actually provides and treat the limitations of that algorithm accordingly.

The safest decision process is therefore simple: confirm the official source, confirm the exact file and algorithm, compare the complete checksum, and use the file only when the values match. For sensitive installations, add signature verification rather than relying on a checksum alone.