How to Verify Software Download Checksums

When a project publishes software for download, it often publishes a checksum next to it: a short string of hexadecimal characters such as a SHA-256 digest. Verifying that checksum is the difference between hoping you downloaded the right file and knowing the bytes on your disk match the bytes the publisher intended to ship.

Downloads go wrong more often than people expect. Files get truncated by flaky connections, cached incorrectly by intermediaries, served from compromised or stale mirrors, or quietly replaced by an attacker who gained access to a download server. A checksum comparison catches every one of these cases, because changing even a single bit of the file completely changes its digest.

What a checksum proves, and what it does not

A cryptographic hash function like SHA-256, standardized in NIST FIPS 180-4, maps a file of any size to a fixed-length digest. It is deterministic, so the same file always produces the same digest, and it is designed so that finding two different files with the same digest is computationally infeasible. If your computed digest matches the published one, you have the exact file the publisher hashed.

That is all it proves. A matching checksum says nothing about whether the software is safe, well-written, or free of malicious code, and it only ties the file to whoever published the checksum. If an attacker controls the download page itself, they can replace both the file and the checksum together, and verification will happily pass.

Verifying a checksum step by step

The process is the same everywhere: obtain the expected digest from the publisher, compute the digest of the file you actually downloaded, and compare the two completely, not just the first few characters.

SecretPNG's file hash tools compute digests entirely in your browser, streaming the file in chunks through a WebAssembly implementation so even multi-gigabyte files never need to be uploaded or held fully in memory. The verify tool takes the expected digest, normalizes formatting differences such as case and whitespace, and gives you a clear match-or-mismatch answer instead of asking your eyes to compare 64 characters.

• Find the official checksum on the project's own site, ideally on an HTTPS page separate from the mirror that served the download.
• Compute the SHA-256 digest of your downloaded file locally.
• Compare the full digest, character for character, against the published value.
• If the digests differ, delete the file and download it again from the official source before investigating further.

Why SHA-256 and not MD5 or SHA-1

Older projects still publish MD5 or SHA-1 checksums. Both functions have known collision attacks: researchers can construct two different files with the same digest, which undermines the guarantee you are relying on. SecretPNG's hashing tools default to SHA-256 and label MD5 and SHA-1 as legacy-only options, provided solely for comparing against old published values, not for establishing trust in new downloads.

A collision attack does not automatically mean an attacker can forge a match for one specific existing file, but the safety margin is gone. When a publisher offers a SHA-256 digest alongside an MD5 one, always verify the SHA-256.

Checksums are the floor, signatures are the ceiling

Some projects go further and sign their releases with a private key, publishing detached signatures you can verify against the project's public key. A signature proves the release came from someone holding that key, which survives a compromised download page in a way a checksum cannot. Where signatures are offered, verify them; where only checksums are offered, verifying them is still far better than verifying nothing.

Make checksum verification a habit for anything you will execute or install, especially operating system images, developer tools, and security software. It takes seconds in the browser and removes an entire class of silent failure.