How to Verify a Download Before You Install It: Checksums and Signatures
A large installer, a firmware image, a set of model weights, an archive pulled from a mirror at 2am. You click, wait, and open it — and you have no way of knowing whether the bytes that landed on disk are the bytes the project produced. Verification closes that gap in under a minute. Here is how to do it on Windows, macOS, and Linux, what a signature adds over a hash, and — importantly — what neither one proves.
The two checks people mix up
Integrity: the file was not truncated or corrupted in transit. A checksum comparison answers this, and it catches the most common real-world failure, which is simply a bad download.
Origin: the file really came from the publisher rather than from someone who substituted it. A checksum published on the same page as the download only partly answers this. A cryptographic signature checked against a public key you established by another route answers it properly.
Neither check tells you the software is free of malicious code or bugs. It tells you that you have exactly the file the publisher shipped, and — with signatures — reasonable confidence about who that was.
Before you start: get the expected value from the right place
Look for a file named something like SHA256SUMS, a "verified hashes" table on the release page, or a checksum listed next to each download link. Two habits matter more than the tool you use:
- Compare the same algorithm. If the publisher posts SHA-256, compute SHA-256. Older projects sometimes publish only MD5 or SHA-1, which still detect corruption but are no longer good enough where deliberate substitution is the concern.
- Get the expected value over a channel you did not get the file from when one exists — the project's main site rather than a random mirror, or a signed announcement rather than the download page itself. This is the step that upgrades integrity checking into origin checking.
Windows
Two options ship with the system. PowerShell's Get-FileHash is the one to prefer; certutil works from a plain command prompt.
Get-FileHash -Algorithm SHA256 -Path C:\Users\you\Downloads\setup.execertutil -hashfile C:\Users\you\Downloads\setup.exe SHA256Get-FileHash defaults to SHA256, prints uppercase hex, and is documented in the Microsoft PowerShell reference. Its output has spaces removed in the hash itself, while certutil wraps the value across lines — if a comparison fails, check you are not just looking at formatting.
Verify a detached signature on Windows
Windows has no built-in GPG. If a project publishes a .sig or .asc file, install GnuPG (or the GPG4Win suite) and use the same commands as the Linux section below. A signature is only as good as the public key you check it with, so import keys from the publisher's stated fingerprint rather than from a keyserver alone.
macOS
macOS ships shasum, which takes the digest algorithm as an option:
shasum -a 256 ~/Downloads/tool.tar.gzThe openssl binary is also present on recent macOS releases and can produce the same digest:
openssl dgst -sha256 ~/Downloads/tool.tar.gzNote that macOS does not include GNU coreutils' sha256sum under that name by default. If you copy commands from Linux documentation and the command is not found, use shasum -a 256 instead of installing anything.
Linux
Coreutils provides sha256sum — see the sha256sum manual page and the wider GNU Coreutils manual:
sha256sum tool.tar.gzThe real value on Linux is batch verification. When a project ships a checksums file alongside several artefacts, run it from the download directory:
sha256sum -c SHA256SUMSEach line is reported as OK or FAILED. Distributions publish hashes the same way: Ubuntu's official hash listings and the Debian security pages both show how publishers present digests for images and updates.
Signatures: the part that establishes who published it
A detached signature is a file created by signing the digest with the publisher's private key. You verify it with their public key:
gpg --verify tool.tar.gz.asc tool.tar.gz
gpg --list-keys --fingerprint PUBLISHER_KEY_IDA good verification line reports a valid signature and a fingerprint. Compare that fingerprint to the one the project publishes in a location that would be harder to swap — its main site, its documentation, or a previous copy you kept. See the GnuPG documentation for option details, since flag behaviour differs between versions.
The hierarchy of trust, weakest to strongest, looks like this: no check at all, then a hash from the same page as the file, then a hash from a channel you separated from the download, then a signature from a key whose fingerprint you confirmed independently. Each step costs a little time and rules out a different class of failure.
When the check fails: what to do
- Re-download before concluding anything. A mismatch most often means an interrupted transfer, a browser that saved a partially written file, or an archive that was re-extracted over itself.
- Check you hashed the right file. Timestamps and duplicate names in Downloads are a frequent cause of false alarms.
- Check the algorithm and encoding. MD5 against SHA-256, uppercase against lowercase, and a checksum file with the wrong filename all produce mismatches that look like attacks.
- Confirm the expected value is current. Projects rebuild releases; a hash bookmarked last month may not match today's artefact.
- If a re-download still mismatches, stop. Do not "just try installing it". Fetch from the project's primary site, and if it still differs, treat the copy you have as untrusted and report it to the project.
Limits worth stating plainly
A verification pass is not a safety verdict. Malicious or simply buggy code signed by the real publisher still passes every check in this guide. Antivirus and reputation tools cover a different risk, and neither replaces the other — our look at the best antivirus software explains what those products actually catch.
Also: verification proves what a file is, not what it will do. An installer can be genuine and still request elevated privileges, phone home, or bundle components you did not choose. Read the permission prompts. A checksum cannot protect you from consent you gave willingly.
A practical minimum, if you do nothing else
- Download from the project's own domain, over the site's HTTPS link — not from a search-ad result or a "download portal".
- Compute SHA-256 on the file and compare it character-for-character with the value on that same site.
- Where the project publishes a signature, verify it against a key whose fingerprint you saw somewhere else.
- Keep the checksum file next to the archive if you store it long term — it is also how you detect bit rot later, alongside the health checks in our drive-health guide.
FAQ
If the checksum matches, is the file safe to run?
No. A matching checksum means the file is identical to what the publisher hashed and arrived intact. It cannot tell you the file is free of malicious code, and it passes even if an attacker replaced both the file and the published value.
Why is the hash published on the same website I downloaded from?
Often that is what a project can offer, and it still catches corruption and mirror tampering. It does not defend against an attacker who controls the site. When both a checksum and a detached signature exist, the signature checked against a separately obtained key is the stronger control.
Do I need to verify files from an app store or package manager?
Not manually. Stores and package managers such as apt or dnf already validate integrity and origin during installation. This guide is for loose downloads: direct installer links, mirrors, firmware files, and model weights.
Is SHA-256 the right algorithm?
Match whatever the publisher posted, and prefer SHA-256 when you choose. MD5 and SHA-1 still reveal a corrupted transfer, but they are not appropriate where you need to rule out intentional substitution.
Related on ToolStep: the installer you check is often one you fetched outside a store — see our OBS Studio setup walkthrough and the OBS alternatives list for cases where the download source varies by mirror. If you are pulling large model files, our open-weight models ranking covers where those artefacts are published and what their licences permit. For the wider security picture, browse security tools.