A practical guide to calculating and comparing file checksums with built-in tools on Windows, macOS, and Linux before installing or archiving downloads.
A published checksum lets you test whether a downloaded file matches the bytes the publisher intended to distribute. This is useful for operating-system images, firmware, software packages, backups, and large archives. The process has two parts: calculate the hash of your local file, then compare it with a value obtained from a trustworthy source. A visual match is not enough if the expected checksum came from the same untrusted mirror as the file.
Prefer SHA-256 or a stronger current checksum when the publisher offers several options. MD5 may still detect an incomplete download or accidental corruption, but it is not reliable against a capable attacker who can construct colliding content. The comparison in MD5 vs SHA-256 explains why SHA-256 is the better default for new workflows.
Copy the expected value directly from the publisher’s official HTTPS page, signed release notes, verified repository, or authenticated package metadata. Confirm the file name and version. A checksum for version 4.2.1 cannot validate version 4.2.2, even when the names look similar.
Modern Windows systems include PowerShell. Open PowerShell, change to the folder containing the download, and run: Get-FileHash .\filename.iso -Algorithm SHA256. Replace filename.iso with the actual file name. PowerShell returns the selected algorithm, the calculated hash, and the file path.
The default algorithm for Get-FileHash is SHA-256, so Get-FileHash .\filename.iso is normally enough. Stating the algorithm explicitly makes scripts and instructions clearer. Microsoft documents the cmdlet in its Get-FileHash reference.
Windows also includes certutil on many installations. The command certutil -hashfile filename.iso SHA256 prints a SHA-256 value. Get-FileHash is usually easier to read and script, while certutil remains useful on systems where PowerShell access is limited.
Open Terminal and use shasum -a 256 filename.dmg for a SHA-256 checksum. The command prints the digest followed by the file name. For an MD5 value required by a legacy publisher, macOS provides md5 filename.dmg, but use SHA-256 when both are available.
Spaces in file names need quoting or escaping. For example, shasum -a 256 "Installer Package.dmg" treats the complete name as one argument. You can also drag a file from Finder into the Terminal window to insert its full path, then place the command before that path.
Most Linux distributions provide sha256sum through GNU Coreutils or an equivalent package. Run sha256sum filename.tar.xz. If the publisher provides a checksum file in the standard format, save it in the same directory and run sha256sum -c checksums.txt. The check mode reads expected values and reports which files pass or fail.
For legacy MD5 lists, md5sum filename or md5sum -c checksums.md5 performs the corresponding operation. Again, this is appropriate for compatibility and accidental-error detection, not adversarial verification.
Hexadecimal hashes are long, and checking only the first or last few characters is unsafe. Compare the complete value. Letter case does not matter for hexadecimal text, but every digit does. Extra spaces usually do not change the meaning when you compare manually, although automated parsers may require a specific format.
A safer manual method is to copy the calculated value and the expected value into a local text comparison tool. In scripts, normalize expected input carefully, reject unexpected characters, and use exact comparison. Do not silently shorten hashes to make logs easier to read when the result controls a security decision.
A matching strong checksum shows that your file has the same digest as the expected file. If the expected value is authentic and the algorithm resists collisions, this is strong integrity evidence. It does not independently prove the publisher’s identity. If an attacker replaces both the download and the checksum on a compromised website, your comparison may still pass.
Digital signatures address that missing origin check. They bind a file or release manifest to a private signing key, while users verify it with the corresponding public key. Package managers often automate this through signed repository metadata. When software is sensitive, verify the signature as well as the checksum.
First, confirm the version, architecture, and file name. Publishers may provide separate images for x86-64, ARM64, server, desktop, and regional editions. Next, download the file again over a stable connection and calculate the hash after the transfer finishes. Do not assume that a browser’s successful-download message guarantees complete content.
If the second download still fails, stop. Do not install or extract the file. Obtain the expected checksum from another official channel, review the publisher’s release page for corrections, and check whether the mirror is current. A mismatch can come from corruption, a stale checksum, a changed file, or malicious replacement; the checksum alone cannot tell you which.
For one file, a manual command is enough. For regular downloads, use a script that records the source URL, expected algorithm, full expected digest, calculated digest, timestamp, and result. Preserve signed checksum manifests with archived releases. This creates a repeatable trail and prevents verification from becoming a vague box-ticking exercise.
The central rule is simple: use a current hash, obtain the expected value through a trusted path, compare the full digest, and stop when it does not match. Those four habits turn a checksum from decorative text into a useful integrity control.