A Worked Example First
Say you download a Linux distribution ISO and the project's site lists this next to the download link:
SHA256 (linuxdistro-12.4.iso) = 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08On your own machine, you run the hash command against the file you just downloaded and get back:
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08Those two strings are identical, character for character. That match means your copy is bit-for-bit the same file the project published: nothing was truncated mid-download, nothing was altered by a flaky mirror, and no malware was inserted along the way. Now imagine your computed hash came back instead as 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a09, different in the very last character. One flipped character means a completely different file. SHA-256 is designed so that changing a single bit of input scrambles the entire output; there is no such thing as "close enough" with a hash. That is the whole tool, and everything else in this guide is detail around using it correctly.
Running the Hash on Each Operating System
Windows, macOS, and Linux all ship a SHA-256 tool already, so nothing extra needs to be installed.
Windows, PowerShell (built into Windows 10 and 11):
Get-FileHash .\yourfile.iso -Algorithm SHA256Windows, Command Prompt, if you prefer it or PowerShell is not handy:
certutil -hashfile yourfile.iso SHA256macOS, Terminal:
shasum -a 256 yourfile.dmgLinux, any distribution with coreutils:
sha256sum yourfile.tar.gzAll four print a hex string. Case does not matter when comparing (hex is case insensitive by convention, and our hex explainer covers why), so 9F86... and 9f86... represent the same value.
Verifying a Whole Batch at Once
Many Linux projects and some cross-platform tools publish a single SHA256SUMS file listing every download's expected hash. Rather than comparing strings by eye, point the command at the file:
sha256sum -c SHA256SUMSThis recomputes the hash of every file named in SHA256SUMS that is present in your current folder and prints OK or FAILED next to each one. It is the cleanest workflow available whenever a project offers it, because it removes the risk of a human misreading two long hex strings.
Why Eyeballing Two Hashes Is Riskier Than It Looks
A 64 character hex string is genuinely hard to compare visually, and a well known shortcut people take is glancing only at the first few and last few characters. That shortcut is exactly what a tampered file with a crafted, similar-looking hash would rely on. Better approaches than eyeballing:
- Paste both strings into a text editor, one per line, and use the editor's built in text comparison or a dedicated diff tool to spot any difference instantly.
- On Linux or macOS, store the expected hash in a file and use
diffor a simple shell comparison rather than reading it yourself. - Use the
-cchecking mode shown above whenever a project provides a sums file, since it does the exact-match comparison for you. - For hashing short text snippets, or to get comfortable with what SHA-256 output actually looks like, our browser-based hash generator computes SHA-256 alongside MD5, SHA-1, and SHA-512 entirely client-side. It is a good way to learn the mechanics; for large binary files, the native OS commands above are the right tool.
Where the Expected Hash Actually Needs to Come From
Verification only proves something if the hash you are comparing against is trustworthy. If an attacker had already compromised the download page, they could swap both the file and the published hash together, and your comparison would happily confirm a match against a malicious file. This is why the source of the expected hash matters as much as the comparison itself:
- Get it from the official project site over HTTPS. The encrypted, authenticated connection (explained in our HTTPS and TLS guide) protects the hash in transit from your browser to the page, though it does not protect against the site itself being compromised.
- Prefer a signed sums file when one is offered. Many open source projects sign their
SHA256SUMSfile with a GPG key that can be verified independently of the website. A valid signature proves the hash list itself is authentic, not merely that your file matches whatever hash happened to be posted. - Cross-check on high-stakes downloads. For an operating system image or security software you are about to install with elevated privileges, checking the hash against a second independent source (a mirror, an official mailing list announcement, a release notes page) adds a meaningful layer of confidence beyond a single web page.
For routine downloads over HTTPS from an official site, computing and comparing the hash already catches the two most common real-world problems: an incomplete or corrupted download, and a file swapped by a compromised third-party mirror. Save the GPG signature step for downloads where the consequences of running a compromised file would be serious.
Compare the entire 64-character string, not just the first and last handful of characters. That partial-match habit is precisely the shortcut a tampered file is counting on you to take.
Why MD5 and SHA-1 Still Show Up, and Why They Are Not Enough Anymore
Older projects sometimes still publish MD5 or SHA-1 checksums instead of, or alongside, SHA-256. For catching accidental corruption, either still works fine: a corrupted file will not accidentally produce a matching MD5 or SHA-1 hash. For catching deliberate tampering, both are broken in a specific, demonstrated way: security researchers have shown practical collision attacks where two different files, one legitimate and one crafted, can be made to share the same MD5 or SHA-1 hash. That means an attacker with enough effort could construct a malicious file matching a legitimate MD5 or SHA-1 checksum. SHA-256 has no known practical collision attack, which is why it is the standard for security-relevant verification today. Treat an MD5 or SHA-1 match as evidence the download was not corrupted, and nothing more. The deeper technical comparison lives in our SHA-256 vs MD5 post, and the underlying concept of one-way fingerprints is covered from the ground up in our hashing guide.
Frequently Asked Questions
My computed hash does not match the published one. What should I do?
Do not run the file. Re-download it first, since an incomplete or interrupted download is the most common cause of a mismatch, then recompute the hash. If it still does not match, try an alternate official mirror and double-check you are comparing against the current published hash rather than an outdated one from an old page. A mismatch that persists across a clean re-download means the file is not what the publisher actually released.
Does a matching hash mean the file is completely safe to run?
It means the file is authentic, identical to what the publisher released, nothing more and nothing less. If the publisher's own release happens to be compromised or malicious at the source (which has happened to real projects after a breach), a matching hash will not reveal that. Verification confirms integrity in transit, not the trustworthiness of the source itself, which is why downloading only from official, reputable sites still matters.
Why did I get a different hash for what looks like the same file?
SHA-256 is fully deterministic: the same bytes always produce the same hash, on any machine, any operating system, any time. A different result means you are hashing different bytes, most commonly because the download was still in progress and incomplete, or because you accidentally hashed a different file with a similar name. A completed, correct file yields the same hash everywhere, always.
Can I verify a checksum on my phone instead of a computer?
Yes, using a dedicated hash calculator app, though it is less common than doing it on a desktop. For short text or small data rather than large binaries, our hash generator runs entirely in the browser and works on mobile. Verifying a multi-gigabyte OS image is generally smoother on a desktop with the native commands covered above.
What is the actual difference between a checksum and a digital signature?
A checksum, meaning a hash like SHA-256, proves the file was not altered, but only if you already trust wherever you got the expected hash from. A digital signature goes a step further: it proves the hash itself genuinely came from the real publisher, using their private cryptographic key, which closes the gap of "what if the hash on the page was swapped too." A signature is effectively a checksum with an added, verifiable claim of authorship, which is why security-critical downloads should use one when it is offered.
