How to Verify a File Checksum

Checksum verification calculates a file's hash locally and compares it with the value published for the intended release.

A file checksum is a value calculated from the file's contents. Verification means calculating that value on your copy and comparing it with the value published for the release. An exact match shows that both values describe the same bytes; a mismatch means they do not.

Checksums are especially useful for large installers, disk images, archives, and files transferred through mirrors. They catch incomplete downloads, storage errors, accidental changes, and many forms of tampering. They are not a malware verdict and do not identify who created the file.

The short procedure

Find the checksum on the project's official release or download page.
Confirm the algorithm, usually SHA-256 or SHA-512.
Confirm the checksum belongs to the exact version and filename you downloaded.
Calculate the same algorithm over the local file.
Compare the two complete values.
Do not run the file if they differ.

A checksum comparison is case-insensitive for hexadecimal letters, but every digit must otherwise match. Spaces added for readability can be ignored; missing or changed characters cannot.

What a checksum looks like

Projects often publish a hexadecimal string beside each file. A SHA-256 value contains 64 hexadecimal characters, using digits 0–9 and letters a–f. A SHA-512 value contains 128. MD5 has 32 and SHA-1 has 40, but those older algorithms are not suitable when an attacker might deliberately create collisions.

The word checksum is broad. It can describe simple error-detection codes as well as cryptographic hashes. Software release pages normally mean a cryptographic file hash when they label values SHA-256, SHA-512, or similar.

NIST's Secure Hash Standard describes hash algorithms that create message digests and are used to detect whether a message has changed. The cryptographic-hash guide explains the underlying properties without requiring mathematics.

Verify a checksum on Windows

PowerShell includes Get-FileHash. It calculates SHA-256 by default, but stating the algorithm makes the comparison clearer:

Get-FileHash "C:\Users\You\Downloads\example-4.2.0-x64.exe" -Algorithm SHA256

The result includes the algorithm, hash, and path. Compare the Hash value with the official SHA-256 value for example-4.2.0-x64.exe.

You can ask PowerShell to compare the values directly:

$expected = "PASTE_THE_OFFICIAL_SHA256_VALUE_HERE"
$actual = (Get-FileHash ".\example-4.2.0-x64.exe" -Algorithm SHA256).Hash
$actual -eq $expected

True means the strings match. False means they do not. This command does not judge whether the publisher or official value is trustworthy; it only performs the comparison.

Microsoft notes that changing even one character of a file changes its hash value. Its documentation also warns that MD5 and SHA-1 should not protect files against malicious alteration. Prefer SHA-256 or stronger when the publisher provides it.

Verify a checksum on macOS

macOS includes shasum. For SHA-256, open Terminal and run:

shasum -a 256 ~/Downloads/example-4.2.0.dmg

For SHA-512:

shasum -a 512 ~/Downloads/example-4.2.0.dmg

Terminal prints the calculated value and filename. Compare the value with the one published for that exact disk image.

Paths containing spaces need quotation marks:

shasum -a 256 "/Users/You/Downloads/Example App 4.2.0.dmg"

Dragging a file from Finder into the Terminal window can insert its path, which reduces typing mistakes. Do not include text from the sample commands literally when your filename is different.

Verify a checksum on Linux

GNU/Linux systems commonly provide a separate utility for each SHA-2 length. For SHA-256:

sha256sum example-4.2.0.tar.xz

For SHA-512:

sha512sum example-4.2.0.tar.xz

If the project publishes a checksum file in the standard format, place it beside the download and use check mode:

sha256sum --check SHA256SUMS

The output should identify the intended file as OK. A checksum list may cover several platform packages, so make sure the result refers to the file you plan to use.

Package managers often verify repository metadata and packages automatically. That is one reason a configured package repository can offer a stronger chain than copying a bare hash from an arbitrary webpage. Read what a package manager does for the wider update and dependency context.

Match the algorithm, version, and artifact

Many apparent mismatches come from comparing the wrong things. Before assuming corruption, check:

Algorithm: SHA-256 output will never equal SHA-512 output.
Version: 4.2.0 and 4.2.1 are different releases.
Platform: Windows, macOS, and Linux files have separate values.
Architecture: x64 and ARM64 packages are different files.
Artifact: installer, portable archive, source archive, and signature file are not interchangeable.
Compression: hashing a downloaded .zip is not the same as hashing a file extracted from it.
Timing: a project may have replaced a release; look for an announcement before accepting a new value.

The checksum is calculated over exact bytes. Renaming a file without changing its contents does not change the hash, but extracting, recompressing, editing, line-ending conversion, or metadata embedded inside the file will.

Where the expected value should come from

The expected checksum is part of the trust decision. Prefer, in order of context:

A signed release manifest or repository metadata validated by tools you trust.
The project's official release page reached through its known domain.
A reputable distributor's record for the file it serves.
A second authenticated channel maintained by the publisher.

Avoid treating a hash copied from the same untrusted page as independent proof. If an attacker replaced both the file and its displayed checksum, the values will match. HTTPS helps protect the connection to a domain, but you still need confidence that it is the correct domain and publisher.

A digitally signed checksum list can strengthen the chain: first verify the signature on the list, then use the authenticated list to verify the file. That process depends on already having the correct public key or certificate. The software-signature guide explains why identity and key trust are separate from the hash calculation.

What a match proves

A matching cryptographic checksum is strong evidence that your file is byte-for-byte the file represented by the expected hash. It can show that a download completed correctly and was not altered after the reference value was created.

It does not prove:

that the original file is free of malware or vulnerabilities;
that the person publishing the value is the developer you intended;
that the publisher's website or build system was uncompromised;
that the software behaves as advertised;
that the release is current or supported;
that the binary corresponds to publicly available source code.

Use checksum verification as one layer in the safe-download checklist, alongside source identity, release context, platform protections, and appropriate permissions.

What to do with a mismatch

Do not open, install, extract, or forward the file. Recheck the algorithm and ensure you copied the full expected value without punctuation or a neighboring file's hash. Confirm the version, operating system, architecture, and filename.

If the inputs are correct, delete the file and download it again from the official path. Recalculate the checksum. A repeated mismatch needs an explanation from the publisher or distributor; it is not a warning to bypass.

In an organization, record the source URL, download time, filename, size, expected hash, calculated hash, and tool used. That information lets a security or support team distinguish a local transfer problem from an upstream change.

Checksums and digital signatures solve different problems

Question	Checksum comparison	Digital signature verification
Did these bytes change?	Yes, when compared with the correct reference	Yes, for the signed content
Who approved the bytes?	Not established by the hash alone	Connected to a signing identity and trust chain
Does it need an expected value?	Yes	The signature contains verification data, but trusted roots or keys are still needed
Can it prove the software is harmless?	No	No
Is it easy to publish for every artifact?	Yes	Requires key management and signing support

The two can complement each other. A project may sign a checksum manifest, publish hashes for mirrors, and sign supported executable formats. Each signal covers a different part of the delivery chain.

A reliable habit for important downloads

When a publisher provides SHA-256 or SHA-512 values, checking them takes less time than recovering from a corrupted system image or untrusted installer. Use the platform's built-in command, compare the exact artifact, and stop on a mismatch.

Remember the limit: equality means the file matches the reference. Confidence in the reference comes from the channel, publisher identity, signatures, and release process around it.