You click the download link on a project's release page. A 200 MB installer lands in your downloads folder. You double-click it, walk through the wizard, and the software is on your machine. Most of the time nothing is wrong with that flow. But every few years a project's mirror or CDN gets compromised, and the installer that looked normal turns out to have shipped with a backdoor that nobody noticed for weeks.
Verifying the file's checksum against the value the project author published is the cheap, boring step that catches this. It takes thirty seconds once you have a workflow. The hard part is knowing which hash to use, where the trusted value lives, and how to handle the mismatch case when it actually happens. This guide walks through it end to end.
Photo by David McElwee on Pexels
What a Checksum Actually Tells You
A published checksum is a fingerprint the project's authors computed over the exact bytes of the release file before they uploaded it. Modern projects publish SHA-256 values; older ones may still list MD5 or SHA-1 alongside.
When you hash the file you downloaded and the result matches the published value, you have evidence that no bit changed between the author's machine and yours. A flipped bit from a corrupted download will produce a wildly different hash. A malicious swap on a mirror will too, unless the attacker also managed to substitute the published checksum on the same page (which is the failure mode signing keys exist to prevent).
A matching checksum does not prove the file is safe in absolute terms. It proves the file is identical to what the project author signed off on. That distinction matters: if the author's build pipeline itself was compromised, the published hash will match the compromised binary. Checksum verification is one layer of defense, not the whole stack.
Where to Find the Trusted Hash
The trusted value should come from a different channel than the binary itself. If you download both from the same mirror, an attacker who controls the mirror controls both. Sources worth treating as trusted:
The project's own GitHub release page, viewed over HTTPS, with the hash listed in the release notes or in a SHA256SUMS file uploaded alongside the binary. Releases on github.com are served by GitHub's infrastructure, not the project's mirror.
A signed announcement: a release email signed with the project's PGP key, a blog post on the project's primary domain rather than a download mirror, or a hash listed inside a signed git tag.
The package manager metadata for projects distributed through Homebrew, apt, or similar systems. These tools verify checksums before installing, and the checksum lives in a manifest signed by the repository.
The published value should never come from the same URL as the file you downloaded. If the only place you can find the hash is the download mirror's HTML page, the verification still catches accidental corruption in transit but is weak against a deliberate attack on the mirror.
The Three-Step Workflow
The workflow is the same regardless of which hashing tool you use. Get the hash of your file, get the published hash, compare. Manual byte comparison is fine for short hashes; for SHA-256 most people skim the first and last few characters and look at the middle for surprises.
Step One: Hash the File You Downloaded
On macOS or Linux, the command-line tool shasum -a 256 filename returns the SHA-256 digest. Windows users can use Get-FileHash -Algorithm SHA256 filename in PowerShell, which has shipped with the OS since Windows 8.
A web-based hash generator that runs the computation client-side in your browser is a useful alternative when you want to verify a file without leaving a command-line history of every binary you've ever inspected. The free hash generator from EvvyTools handles MD5, SHA-1, SHA-256, SHA-512, and HMAC-SHA256 entirely in-browser, so the file you're checking never leaves your machine even though the tool itself loads from a website.
Photo by Paul Seling on Pexels
Step Two: Get the Published Hash
Pull the project's published hash from the most trusted channel available. A SHA256SUMS file alongside the release on a release page is the common pattern. Some projects publish both SHA256SUMS and SHA256SUMS.asc, which is the same hash list signed with the project's PGP key. If you have the project's public key already verified, checking the signature on the hash file adds a second layer of certainty.
If the project only lists hashes in their release notes, copy the value directly from the HTTPS-served release page. Treat any hash that arrived over plain HTTP, in an unsigned email, or in a forum post as untrusted.
Step Three: Compare Carefully
Both hashes should be identical character for character. A SHA-256 digest is 64 hex characters; a SHA-512 is 128. Case does not matter (most tools output lowercase) but every character does. Paste both into a text editor and visually compare, or use a diff command on two text files containing the two hashes.
Avoid the temptation to compare only the first eight characters. Real-world tampering attempts have included files whose hash collisions matched a small prefix and people only checked the prefix.
When the Hashes Do Not Match
A mismatch is information, not necessarily a security incident. Walk through the explanations in order before assuming foul play.
Did the download complete? A truncated file produces a different hash but is not malicious. Check the file size against what the release page lists, and retry the download if the size is off. Many download tools resume partial downloads and may leave the file in an inconsistent state if interrupted mid-stream.
Are you comparing the right hash for the right algorithm? SHA-256 of the file you downloaded should match the project's published SHA-256, not their SHA-1 or MD5. Mixing algorithms is a common operator error when a release page lists multiple hashes.
"When clients ask me what one habit makes the biggest difference in keeping their supply chain clean, I always say verifying release hashes is the cheapest, highest-leverage thing. It's the difference between catching a compromised mirror in thirty seconds versus six weeks of incident response. The cost is so low there's no good excuse to skip it." - Dennis Traina, founder of 137Foundry
Did you download the right file? Some projects publish separate binaries for different architectures or operating systems, each with its own hash. A SHA-256 for the x86_64 build will not match the ARM64 build's hash even though the version number is the same.
Did the project update the file in place? Reputable projects do not. If a release page rewrites a binary under the same filename without bumping the version number, that itself is a process problem worth raising with the maintainers, but the hash mismatch in that case is administrative rather than malicious.
If none of those explain the mismatch, treat the download as untrusted. Do not run the installer. Re-download from the project's primary distribution channel rather than the mirror you used the first time, and verify against the same published hash. Two independent downloads producing the same wrong hash is a stronger signal than one.
Photo by Polina Tankilevitch on Pexels
Verifying Multiple Files Without Doing It By Hand
When a release ships a dozen files (Linux binary, Windows installer, macOS DMG, source tarball, signature files), checking each by hand gets tedious. The pattern most projects support: download the SHA256SUMS file, then run sha256sum -c SHA256SUMS in the directory containing the downloads. The tool hashes each file listed in the manifest and prints OK or FAILED for each line.
This works because SHA256SUMS is a plain-text file with one line per release artifact, in the format <hash> <filename>. The -c flag tells the tool to verify rather than compute.
For Windows users without WSL, the same workflow is possible with Get-FileHash in a script that loops over the manifest. Several open-source community scripts implement this; check the project's documentation for their recommended approach on Windows.
If you regularly verify releases as part of an automated build or deployment pipeline, integrate the check into the script that downloads the artifact. Fail loudly on a hash mismatch rather than silently proceeding with an unverified file. A pipeline that runs unverified binaries is functionally indistinguishable from no verification at all.
HMAC Versus a Plain Checksum
A plain SHA-256 verifies that the file matches what the publisher committed to. It does not verify who the publisher is. For that, you need either a digital signature (PGP, Sigstore, code-signing certificates) or HMAC with a shared secret key.
HMAC-SHA256 shows up most often in API request signing rather than file release verification. Webhook providers like Stripe and GitHub use HMAC-SHA256 so the receiving server can confirm the request came from someone who knows the shared secret. The same hashing primitive applies, but the workflow is request-by-request rather than file-by-file.
If you are setting up webhook verification on your end and want to confirm your HMAC implementation produces the same output the sender expects, hashing a test payload with a known secret and comparing the result against the sender's documented examples is the fast way to debug it. The EvvyTools tools directory includes the Hash Generator alongside JWT decoders, UUID generators, and other developer utilities that fit into security and integration workflows.
For a deeper explanation of how SHA-256, SHA-512, and the rest of the hash family compare across security properties and use cases, the EvvyTools blog covers the algorithm choices in detail, including why MD5 and SHA-1 should not be used for new security-sensitive work.
What to Do If You Cannot Find a Published Hash
Some smaller projects do not publish checksums. This is unfortunate but common, particularly with personal projects or early-stage tools. If the project has a public git repository, you can sometimes verify by building from source rather than downloading a binary. Reading the source and compiling it yourself is more work but eliminates the trust dependency on the binary distribution.
If you must use the binary and no hash is published, downloading from multiple geographically distinct mirrors and comparing hashes between them is a weak form of verification. If all mirrors return the same file, an attacker would need to compromise multiple mirrors simultaneously to swap the binary, which raises the bar. This is not as good as a publisher-signed hash but is better than no check at all.
A more reliable long-term answer: ask the project to publish hashes. Most maintainers add a SHA256SUMS file to their release process willingly when someone explains the value. Opening an issue with a polite request and a link to how other projects in the same ecosystem do it works more often than not.
A Habit Worth Building
Hash verification is one of those small habits that almost never matters and occasionally matters a lot. The five times in a career when you catch a corrupted download or, rarely, a compromised mirror, pay back the cumulative time of every check you ran where nothing was wrong.
The minimum viable habit: any binary you install on a machine that handles production credentials, sensitive data, or anything that could be exploited downstream gets verified against the project's published SHA-256 before you run it. Browser-installed extensions, package-manager-installed tools, and apps from official app stores are already verified by their respective platforms; the manual check matters most for direct downloads from project release pages.
The SHA-2 family on Wikipedia covers the algorithm internals if you want to understand what the comparison is actually doing under the hood. The OWASP cheat sheets include guidance on integrity verification practices, and NIST maintains the current authoritative recommendations on which hash algorithms remain approved for federal use. These are the references worth bookmarking if you find yourself building out a verification workflow for your team.
The verification step itself takes seconds once the muscle memory is built. The hard part is starting; the easy part is keeping it.
