A release page gives you a SHA-256 value next to a download. Comparing it with your file can catch a corrupted transfer or the wrong archive before you install anything. The useful check has three parts: hash the exact file, compare the entire digest, and establish why you trust the expected value.

Start with the publisher's expected value

Open the software project's official release page and select the checksum for the exact version, operating system, architecture and archive format you downloaded. A Linux ARM archive and a Windows x64 archive should not have the same checksum.

Use the publisher's documented verification process when one exists. A digest copied from a forum post or an unrelated download mirror is not a reliable reference. If a project publishes a signed checksum list, verify its signature using a signing key or identity authenticated through the project's documentation.

Hash a file on Linux

Run this in the folder containing your download. Replace the filename with your actual archive; quote filenames that contain spaces.

sha256sum "download.tar.gz"

The output starts with a 64-character hexadecimal digest, followed by the filename. Compare all 64 characters with the expected SHA-256 value. A matching beginning or ending is not sufficient. Hexadecimal letter case does not change the digest.

If the publisher provides a trusted checksum file in the standard format, GNU tools can check its entries automatically:

sha256sum --check SHA256SUMS

Read the result for your actual file. Missing files and failed checks are not successful verification. Do not rename an unrelated checksum file or select an entry only because its filename looks similar.

Use macOS or Windows tools

On macOS, the bundled shasum command can calculate SHA-256:

shasum -a 256 "download.tar.gz"

In Windows PowerShell, request SHA-256 explicitly so the example states the algorithm it expects:

Get-FileHash -Algorithm SHA256 -LiteralPath '.\download.zip'

The Hash field contains the digest. Use the Path field to confirm that PowerShell read the intended file. The commands read file contents; neither the extension nor the filename proves what is inside.

Try a reproducible example first

In a new scratch folder, create a file containing exactly five UTF-8 bytes: hello, without a newline. On a Unix shell:

printf '%s' 'hello' > hello.txt
sha256sum hello.txt

The expected SHA-256 digest is:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Now create the file using printf 'hello\n' and calculate again. The result changes because the newline is a sixth byte. This explains many apparent disagreements between a text hash and a file hash: line endings, encoding, byte-order marks and trailing spaces all matter.

The QuickWebTools Hash Generator accepts text. You can enter hello to reproduce the five-byte example. It is not a file checksum uploader, and copying binary download contents into a text box is not an equivalent verification method.

What a matching digest proves

A match is strong evidence that your file has the same bytes as the file represented by the trusted digest. It does not prove that the software is harmless, that the publisher's account is uncompromised, or that you obtained the expected value from a trustworthy place.

If an attacker replaces both an archive and its checksum on the same compromised page, those two values can agree. A correctly verified digital signature can provide an additional authenticity check, but only when you trust the signing key or identity through an independent process.

When a checksum does not match

Do not install the file while investigating. Check the version and architecture, confirm the algorithm is SHA-256, and calculate against the downloaded archive rather than an extracted member. Download again from the official source. If the mismatch persists, consult the publisher's release notes or support channel rather than choosing a checksum that happens to match.

For new verification workflows, prefer the publisher's SHA-256 or stronger option. MD5 and SHA-1 still appear in legacy lists, but they should not be your choice for protection against deliberate tampering.

References