Verify a software download with a SHA-256 checksum

Choose the reference before measuring the download

Start at the publisher’s official website, then follow its release or download links. A checksum copied from an unsolicited message or an unrelated download directory has no useful authority. HTTPS protects the connection to the domain you visit; still check that it is the publisher’s intended domain.

Identify the exact release, operating system, processor architecture and package format. A Windows Arm installer, Windows x64 installer and portable ZIP are different files even if the product version matches. Find the SHA-256 entry for the exact package you saved. Do not substitute a SHA-512, SHA-1 or MD5 value.

Record the release-page URL, filename and expected checksum together. A SHA-256 value in ordinary hexadecimal form has 64 characters using digits and letters A–F. That length is a useful transcription check, not proof that the value came from the publisher. Copy the complete value, excluding labels and filenames.

Make the file you check the file you will use

Wait until the browser reports that the download has finished. Do not hash a partial-download file, an extracted application or a shortcut to the installer. If your browser extracts archives automatically, locate or download the original archive corresponding to the published checksum.

Look for duplicate names such as CedarEdit-4.2-windows-x64 (1).zip. A changed filename alone does not change the contents, but it makes selecting the wrong copy easier. Choose one exact path and keep it for the entire check. Put the package in a folder you can identify, and leave it unchanged until you decide whether to use it.

All examples assume the file is in your account’s Downloads folder. If yours is elsewhere, replace that path too. Quote paths containing spaces. Administrator privileges are unnecessary for reading a download you already have permission to access.

Windows: calculate and compare in PowerShell

Open PowerShell and run this with your actual filename. Microsoft documents Get-FileHash, including SHA256 and literal paths that avoid wildcard interpretation.

$file = "$env:USERPROFILE\Downloads\CedarEdit-4.2-windows-x64.zip"
Get-FileHash -LiteralPath $file -Algorithm SHA256

Check that the output names SHA256 and the intended path. The Hash field is the calculated value. To compare it without visually inspecting every character, run:

$expected = (Read-Host 'Paste the publisher SHA-256').Trim()
if ($expected -notmatch '^[0-9A-Fa-f]{64}$') {
    throw 'Expected checksum must contain exactly 64 hexadecimal characters.'
}
$actual = (Get-FileHash -LiteralPath $file -Algorithm SHA256 -ErrorAction Stop).Hash
$actual -eq $expected

True means the values match; False means they differ. This comparison ignores letter case. An exception, access error or missing-file message is an incomplete check, not a match. Resolve the path or permissions and rerun it.

macOS: request SHA-256 explicitly

In Terminal, use the shasum route if that command is available:

shasum -a 256 "$HOME/Downloads/CedarEdit-4.2-macos-arm64.zip"

The Perl shasum manual documents -a 256. Omitting it normally selects SHA-1, which will not match a SHA-256 reference. The result contains a digest followed by the filename; compare only the 64-character digest with the publisher’s value.

For a manual comparison, place the two full values in a local text document on adjacent lines, use the same letter case and examine consecutive groups of eight characters. All eight groups must agree. A matching beginning and ending is insufficient. If Terminal says the command is unavailable, stop and use a documented local hashing tool; an online upload service is unnecessary.

Linux: read a digest or check a manifest

With GNU coreutils available, calculate the file’s digest:

sha256sum "$HOME/Downloads/CedarEdit-4.2-linux-x64.tar.gz"

Compare the complete digest as described above. The coreutils manual page also documents checking a checksum manifest with -c. If the publisher supplies a compatible SHA256SUMS file, save it alongside the package, then run:

cd "$HOME/Downloads"
sha256sum -c SHA256SUMS

Find the line for your exact package. Its success result ends in OK; FAILED means a mismatch. Missing-file errors can refer to other packages listed in the manifest. Those files have not been verified, even when your package passes. If the manifest format is rejected, calculate the individual file’s hash and compare it with its published entry instead.

Use a mismatch to narrow the problem

Suppose, hypothetically, your macOS archive differs from the reference. You discover that you copied the checksum for the Intel package while downloading the Arm package. The comparison correctly rejected the pairing. Select the intended architecture, retrieve the corresponding reference and repeat the check. Do not edit a checksum until the result turns green.

A mismatch alone does not identify an attacker, a damaged drive or a broken network. Those are explanations requiring additional evidence. When contacting the publisher, include the release URL, package name, algorithm, expected value and calculated value. Redact your local username from terminal output. This gives support a reproducible comparison without uploading the installer.

Know exactly what a pass permits

A matching hash establishes agreement with your reference to a very high degree of confidence. It does not establish that the software is harmless. If someone can replace both the package and the checksum you trust, the comparison can pass for their replacement.

Some projects authenticate their checksum manifests with digital signatures. Canonical’s Ubuntu verification guide separates checking the manifest’s signature from checking the downloaded image. Follow your publisher’s own signature instructions, including verification of the signing-key fingerprint through a trusted reference. A successful signature check with an unverified key does not settle who owns that key.

Keep the checksum result, source URL and release identification if you will reuse or share the package later. Recheck after copying it to another drive if you need assurance about that copy. If the file changes or you replace it with a newer release, repeat the comparison against the corresponding reference.

Finally, open the same file you checked. Continue with inspecting the installer’s offers and respect operating-system security warnings. A checksum pass answers the file-integrity question; deciding to trust and install the product still requires judgment.