What checksums are for: verifying a download with a hash
Calculate a file's SHA-256 checksum, compare the complete value with the publisher's, and understand what a match does and does not establish.
By ToolsNow · Published · updated
To check a download against a publisher’s SHA-256 checksum, hash the downloaded file and compare the entire 64-character value. A mismatch means the bytes do not match that checksum. A match is strong evidence of identical bytes, provided the expected checksum is trustworthy.
Use the checksum for the exact version and file you downloaded. An installer, its ZIP archive and the extracted files each have their own bytes and therefore their own hashes.
Calculate the hash of the file
Open a terminal in the directory containing the file, or replace the example with its full path. These commands calculate a checksum without running the downloaded file.
On Windows, in PowerShell:
Get-FileHash -LiteralPath "installer.iso" -Algorithm SHA256
On macOS, where shasum is available:
shasum -a 256 "installer.iso"
On Linux with GNU coreutils:
sha256sum "installer.iso"
The filename is an example, not a file supplied by this guide. Keep quotes around paths containing spaces. Check that the selected algorithm is SHA-256 rather than SHA-1 or another similarly named option.
Compare all the digits
Read the full hash column, ignoring only hexadecimal letter case: A
and a represent the same value. Do not check just the first and last
few characters. Partial comparison throws away much of the protection
provided by the full digest.
If the publisher supplies a checksum manifest in the supported format, GNU’s command can compare its listed files automatically:
sha256sum --check "SHA256SUMS"
Run this from the directory where the manifest’s relative filenames make sense. Check the result for the particular file you downloaded; a manifest may also list files you did not download. The GNU SHA-2 utility reference documents these checksum commands.
When the values differ
First check the filename, version, architecture and algorithm. Then check whether the download finished and whether the expected checksum belongs to the compressed file or an extracted one.
If those details agree, obtain a fresh copy from the publisher and compare again. Do not use a mismatching installer while assuming the difference is harmless. The checksum cannot tell you whether the cause is an incomplete transfer, a changed release, accidental corruption or tampering.
Re-saving a text file with different line endings, adding a newline or repacking an archive can change its hash without visibly changing its content. Hashing compares bytes, not meaning.
A matching checksum does not identify the publisher
If an attacker can replace both a download and the checksum beside it, the two can still match. The check then confirms consistency with the replacement value, not that the intended publisher produced the file.
A checksum obtained through a trusted channel provides a useful reference. A verified digital signature can additionally authenticate the signer, provided you have established trust in the signing key. Follow the publisher’s signature-verification instructions when they supply them.
Neither a checksum nor a signature proves that software is bug-free or safe in every other respect.
Why SHA-256 is a useful default
A cryptographic hash condenses an input into a fixed-size digest. SHA-256 produces 256 bits, written as 64 hexadecimal characters. The same bytes produce the same digest; finding different inputs with the same SHA-256 digest is intended to be computationally impractical.
Collisions are mathematically possible. The practical requirement is resistance to finding them, not a guarantee that no collision can exist. MD5 and SHA-1 have known collision weaknesses and should not be chosen for new security-sensitive verification. CRC32 is an error-detection checksum, not a cryptographic substitute.
If a publisher supplies only an older checksum, it can still help detect accidental corruption. It does not gain modern collision resistance just because it matches.
Hashing text is a different input path
The hash generator hashes entered text as UTF-8 in the browser. It offers MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC32; it is not a file-upload checksum checker. Pasting a filename hashes the filename, not the file’s contents.
For a reproducible text example, SHA-256 of test, with no trailing
newline, is:
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
A hash is also not a way to make a guessable secret confidential. Password storage needs a dedicated password-hashing design, as covered in the encoding, encryption and hashing guide.
Last reviewed 2 October 2026.
Published by ToolsNow. Read how tools and sources are checked.
Found a mistake or an outdated detail? Send a correction with the article title and the detail to review.