How to Verify a File With a SHA-256 Checksum

October 17, 2026 • NOFYI Editorial Team

What a SHA-256 Checksum Is

A SHA-256 checksum is a short fingerprint for a file. It is produced by SHA-256, a widely used hash function. You feed the function the exact bytes of a file, and it returns a fixed-length result: 64 hexadecimal characters. Hexadecimal characters are the digits 0 through 9 and the letters a through f. The result represents 256 bits of output, which is where the name SHA-256 comes from.

The key property is that the fingerprint depends on every byte of the input. If you change one byte, add a byte, remove a byte, or reorder bytes, the output changes. The change is not small or predictable. A tiny difference in the input produces a fingerprint that looks completely different. That property is what makes a checksum useful for checking whether a file is exactly the one you expected.

A checksum is not a summary you can read, and it is not a compressed copy of the file. You cannot turn a SHA-256 hash back into the original file. The function works in one direction only. Given the hash, you cannot reconstruct the file. Given the file, you can always recompute the same hash. That one-way property is normal for a hash function, and it is part of why hashes are used for verification rather than for storage.

Why Verifying a Download Matters

Downloads can be damaged or changed in several ways. A download can be cut short, a network error can alter bytes, a mirror can host an older or modified copy, or an attacker can replace a file on a compromised server. In each case, the file on your computer may not be the file the publisher intended to distribute. Installing or running that file without checking it means trusting that nothing went wrong along the way.

Verification gives you a practical check. Publishers often publish a SHA-256 hash alongside a download, on the same download page, in a separate checksum file, or in release notes. If you compute the hash of the file you downloaded and it matches the published hash, you have strong evidence that your copy is byte-for-byte identical to the copy the publisher hashed. If it does not match, something changed, and you should not treat the file as the original.

This check is quick, free, and built into most operating systems. It does not require installing new software, and it takes only a moment once you know the commands. For any important download, especially an installer, a disk image, a firmware file, or an archive containing software, verification is worth the small effort. Skipping it saves a minute and removes the one check that would have caught a corrupted or substituted file.

How to Verify a File Step by Step

Start by downloading the file from the official source whenever possible. Avoid unofficial mirrors and links shared in comments or messages unless you can confirm that they point to the official release. While you are on the official page, copy the published SHA-256 hash. It may be shown directly on the page, or it may be in a file with a name ending in .sha256 or .txt. Keep that published hash in a place where you can compare it character by character.

Next, compute the SHA-256 hash of the file you downloaded, using a tool already on your computer. On Windows, open Command Prompt or PowerShell and run a command in this form: certutil -hashfile followed by the file path and SHA256. On macOS, open Terminal and run shasum -a 256 followed by the file path. On Linux, open a terminal and run sha256sum followed by the file path. In PowerShell, you can also use Get-FileHash with the SHA256 algorithm. Each of these tools reads the file and prints a 64-character hash.

Then compare the two hashes carefully. Do not compare only the first few characters, and do not compare from memory. Place the published hash and the computed hash side by side, or copy them into a text editor, and check every character from start to finish. The comparison is exact: any difference, even in one character, means the files are not identical. A match means the file you have produces exactly the same fingerprint as the file the publisher hashed.

Finally, act on the result. If the hashes match, you have completed the integrity check. You can proceed with the file, while remembering the limits explained below. If the hashes do not match, do not run, install, or open the file. Delete the copy you downloaded, try downloading again from the official source, and check again. If a second download still does not match, contact the publisher through an official channel and do not use the file.

Worked Example: A Small Test File

A good way to learn verification is to try it on a small file you create yourself, where the correct hash is a published test value. Create a plain text file that contains exactly the three characters abc, with no newline at the end. You can do this with a text editor that lets you control the final newline, or with a small command that writes exactly those bytes. Then compute the SHA-256 hash of that file.

The correct SHA-256 hash for the three bytes abc is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. That value is a standard test vector for SHA-256, published with the algorithm, and any correct SHA-256 tool should produce exactly that result for that input. Compare your computed hash with this value character by character. If they match, your tool is working correctly, and you have seen a real verification succeed.

Now change one character in the test file, for example change abc to Abc, and compute the hash again. The new hash will look completely different from the first one, even though only one letter changed. That is the avalanche effect in action: a small change in input produces a large, unpredictable-looking change in output. The same principle applies to a large download. Changing one byte in a large installer changes the hash just as thoroughly, which is why comparing the full 64 characters matters.

Once you have seen this on a test file, repeat the same steps on a real download. Download the file, get the published hash from the official source, compute the hash of the downloaded file, and compare the full strings. The process is identical. The test file simply lets you practise with a known answer before the result matters.

How to Get a Trustworthy Published Hash

A hash is only as trustworthy as its source. If you download a file and its hash from the same compromised page, an attacker who replaced the file could also have replaced the hash. The match would then prove only that the file matches the attacker-supplied hash, not that it is the original file. That is why the source of the published hash matters as much as the hash itself.

Where possible, get the hash from the official publisher, over an encrypted connection, and check that you are on the genuine site. Some publishers also sign their releases with a digital signature, which is a stronger form of authenticity than a plain hash. If a signature is available, verifying the signature is the better check, because it ties the file to a key controlled by the publisher. A plain checksum alone cannot do that.

Be cautious with hashes copied from forums, chat messages, search results, or third-party download sites. Those copies may be mistyped, outdated, or deliberately altered. If the only hash you can find comes from an unofficial source, treat the verification as weaker evidence. In that case, prefer to find the official release page or an official mirror, and use the hash published there.

Common Mistakes When Comparing Hashes

One common mistake is to compare only the start of the hash. Two different files can share a few leading characters by chance, and a human eye can easily miss a difference later in the string. Always compare all 64 characters. Copying both hashes into a text file and using a comparison tool, or comparing them in a terminal, reduces the chance of missing a difference.

Another mistake is to introduce extra whitespace when copying a hash. A trailing space, a line break, or a missing character can make a correct hash look wrong, or make a comparison harder to read. When you copy a hash, copy only the 64 hexadecimal characters. If a checksum file contains a filename after the hash, ignore the filename and compare only the hash itself.

A third mistake is to use the wrong algorithm. Some pages publish MD5 or SHA-1 hashes as well as, or instead of, SHA-256 hashes. Those are different functions with different output lengths. An MD5 hash is 32 hexadecimal characters, and a SHA-1 hash is 40. If you compute a SHA-256 hash and compare it with an MD5 hash, they will never match, even if the file is correct. Always confirm which algorithm the published hash uses, and compute the hash with the same algorithm.

A fourth mistake is to verify the wrong file. If you download a file twice, or if your browser saves a copy with a number added to the name, make sure you hash the copy you intend to use. Hashing an older copy and then installing a newer copy does not verify the newer copy. Keep file names and folders clear, and hash the exact file you plan to open or install.

Limitations of a Checksum

The most important limitation is that a checksum proves integrity, not trust. A matching hash tells you that the file is unchanged since the hash was created. It does not tell you who created the file, whether the original file was safe, or whether the publisher is trustworthy. A malicious file can have a perfectly valid SHA-256 hash, because the hash is computed from whatever bytes the file contains, good or bad.

A checksum also does not prove that the file is free of malware. Antivirus software, code signing, and a trustworthy publisher are separate checks. A matching hash does not replace them. If you would not trust the publisher or the source, a matching hash alone is not a reason to trust the file.

A checksum also cannot prove that the hash itself was not replaced. If an attacker controls the page that lists the hash, they can publish a hash for their own modified file. That is why signatures, official channels, and secure connections matter. A checksum is a strong check against accidental corruption and against substitution where the attacker cannot also change the published hash. It is not a defence against every attack on the distribution channel.

Finally, a checksum does not protect a file after you verify it. If the file is later modified on your computer, the hash you computed earlier will no longer match the file. If you need to check a file again later, recompute the hash at that time and compare it again. Verification is a check of a file at a moment in time, not a permanent guarantee.

Frequently Asked Questions

What should I do if the hashes do not match?

Do not run, install, or open the file. Delete the downloaded copy, download it again from the official source, and verify again. If it still does not match, do not use the file. Report the mismatch to the publisher through an official channel, because the publisher may need to fix a corrupted upload or investigate a compromised mirror.

Is SHA-256 the same as MD5?

No. MD5 is an older hash function with a 128-bit output, shown as 32 hexadecimal characters. MD5 is no longer considered secure for integrity checking against deliberate tampering, because collisions have been demonstrated. SHA-256 has a 256-bit output and is the safer choice for verifying downloads. When a publisher offers both, use the SHA-256 hash.

Can two different files have the same SHA-256 hash?

In theory, collisions must exist, because there are more possible files than possible hash values. In practice, no one has found a collision for SHA-256, and finding one is considered infeasible with current methods. For download verification, you can treat a matching SHA-256 hash as evidence that the files are identical, while remembering that a hash alone does not prove who made the file.

Does a matching hash mean the file is safe?

No. A matching hash means the file is unchanged since the hash was created. It does not mean the file is safe, well written, or free of malware. Safety depends on the publisher, the source, and other checks such as code signing and antivirus scanning. Use the hash as one check in a careful process, not as the only check.

Conclusion

Verifying a file with a SHA-256 checksum is a small habit that prevents a large class of mistakes. Get the published hash from a trustworthy source, compute the hash of the file you downloaded, compare all 64 characters, and act on the result. If the hashes match, you have strong evidence that your copy is identical to the published copy. If they do not match, stop and do not use the file. Never skip verification for an important download, and never treat a matching checksum as proof that a file is safe or that its publisher can be trusted. Integrity and trust are different questions, and a checksum answers only the first one.