Verifying File Integrity with Checksums

Last reviewed on May 11, 2026

A checksum is a short fingerprint computed from a file's contents. Two files that produce the same checksum are byte-for-byte identical; changing even a single bit anywhere in the file produces a completely different checksum. That property is why every major software project publishes checksums alongside its downloads, and why anyone moving important data between systems should be in the habit of checking them.

This page covers the practical mechanics: which algorithm to use, the commands that compute checksums on each operating system, and how to compare a computed value against a published one without falling into the small traps that catch most people on a first try.

What problems checksums actually solve

Checksums are good at telling you that a file you have matches a file someone else expected. They catch:

• Incomplete or interrupted downloads, where the file looks right but is missing a few kilobytes from the end.
• Bit rot on long-stored media, where storage hardware silently flipped one or more bits over time.
• Transfer corruption across USB, network, or sync services that didn't end-to-end validate.
• Tampering during distribution, when the published checksum comes from a separate, trusted channel.

They are not a defence against tampering when the attacker controls both the download and the published checksum on the same page. For that case, cryptographic signatures (PGP, code signing) are the right tool; checksums are about integrity, not authenticity.

Which algorithm to use

Three algorithms account for the overwhelming majority of published checksums:

• MD5 — produces a 128-bit hash (32 hex characters). Still widely seen because it's old and fast, but considered broken for security purposes. Fine for detecting accidental corruption; unsuitable when an attacker may want to forge a matching file.
• SHA-1 — 160-bit (40 hex characters). Same story as MD5: still ubiquitous, but no longer trusted against deliberate attack. Adequate for integrity.
• SHA-256 — 256-bit (64 hex characters). The current default for new projects and the right choice when you have a choice. Slower than MD5 on very large files but the difference rarely matters in practice.

A published download page may list more than one. Match whichever one is published; mixing algorithms doesn't make verification stronger.

Computing a checksum on Windows

Windows ships with certutil, which has computed checksums for decades, and PowerShell's Get-FileHash, which is more pleasant to read. Either works without installing anything.

certutil -hashfile installer.exe SHA256
Get-FileHash installer.exe -Algorithm SHA256

certutil prints a colon-separated hash you'll usually want to strip; Get-FileHash shows the algorithm, the hash, and the path in three clean columns. For MD5 or SHA-1, swap the algorithm name.

Computing a checksum on macOS and Linux

Both ship with dedicated commands per algorithm:

md5sum installer.iso       # Linux
md5 installer.iso          # macOS
sha1sum installer.iso      # Linux
shasum installer.iso       # macOS (defaults to SHA-1)
sha256sum installer.iso    # Linux
shasum -a 256 installer.iso  # macOS

On either platform, the output is the hash followed by the filename. Comparing it to a published value is the next step.

Comparing the result safely

Eye-balling two 64-character hex strings is a recipe for missing a single-character change in the middle. Three safer approaches:

• Copy both values into a text editor and run a "compare lines" command. Many editors highlight any difference between two adjacent lines.
• Use the operating system's own check mode. On Linux, sha256sum -c sums.txt reads a sums file containing the published hash and the filename, and verifies in one step. macOS's shasum -c works the same way.
• Pipe the hash into a string comparison. In PowerShell, (Get-FileHash installer.exe -Algorithm SHA256).Hash -eq "EXPECTED_HASH" returns True or False and removes all ambiguity.

Decision criteria: when to actually bother

Verifying every file you ever touch is overkill. The high-value cases are:

• Operating system installers, BIOS or firmware images, and any download that will be executed with elevated privileges.
• Backups before and after a transfer or restore, especially when moving between filesystems with different size or block alignment.
• Large media files (raw video, virtual machine images, photo archives) shipped over consumer-grade cloud services.
• Anything you intend to keep for a long time. Computing and storing a checksum next to the file gives you a way to detect bit rot years later.

For everyday documents, the network and filesystem layers do enough integrity checking that manual verification would be busywork. Use judgement; checksums are a tool, not a ritual.

Common mistakes

• Trusting a checksum published on the same page as the download. If an attacker can replace the file, they can replace the hash. Cross-check against a different channel (the project's signed release notes, a mirror, or a hash repeated on a different server).
• Comparing different algorithms. An MD5 of your file will never match a SHA-256 of the original. The published value tells you which algorithm it came from.
• Forgetting whitespace. A trailing space in a hash string copied from a webpage can derail the comparison. Trim before comparing.
• Running a hash on a partially downloaded file. If the download manager is still running, the hash will keep changing. Wait until the file is complete.
• Hashing through symbolic links when you meant to hash the target. Be explicit about the path.

What a mismatch means

If a downloaded file's hash doesn't match the published value, the file is not what the publisher released. In order of likelihood: the download was interrupted, a content-delivery network served a stale or partial copy, antivirus modified the file in transit, or — much less commonly — the file was tampered with. The standard recovery is to redownload from the official source, ideally from a different network if available, and re-verify.

A mismatch during a copy or restore points either at the source media (failing drive, dirty disc) or at the destination. Our guide on corrupted files covers what to do next; a second mismatch on the same operation is a strong signal that the storage hardware is failing and should be replaced before any further writes.

Where this fits

Integrity verification pairs naturally with the rest of the safety basics covered on the site: backing up important files means little if you can't tell whether the backup still matches the original, and the slow downloads guide covers the upstream causes of the truncated-file pattern you'll detect here. A short checksum at the end of a large transfer is the cheapest way to make data movement provable.