How to Verify a File Checksum (Step by Step)

You downloaded a 4 GB ISO, a signed installer, or a release tarball, and the publisher listed a long string of hex characters next to the link. Verifying it takes about thirty seconds and answers one specific question: is the file on my disk byte-for-byte identical to the file the publisher built? If a single bit changed — from a truncated download, a corrupted mirror, or deliberate tampering — the digest changes completely and you find out before you run anything.

This is the practical walkthrough. For the underlying theory of why hash functions can make this guarantee, see The Complete Guide to Cryptographic Hashing.

Step 1: Get the Published Checksum

Find the digest the publisher computed on the original file. It usually lives in one of a few places:

• Printed directly on the download page, next to the file link.
• In a companion file — SHA256SUMS, checksums.txt, <filename>.sha256 — sitting alongside the download.
• In the release notes or a GitHub release body.
• Inside a GPG-signed manifest, which is the strongest form.

Note the algorithm, not just the value. A 32-hex-character string is MD5, 40 characters is SHA-1, 64 is SHA-256, 128 is SHA-512. You have to hash your copy with the same algorithm or the values will never match.

One habit worth building: get the checksum from a different place than the file itself where possible. If you download the ISO from a community mirror but pull the digest from the project's primary HTTPS site or its signed manifest, an attacker has to compromise two independent things instead of one. A checksum published on the same compromised page as the file proves nothing at all.

Step 2: Compute the Checksum of Your Copy

You need the digest of the file as it exists on your machine right now.

In your browser. Drop the file into the SHA-256 Hash Generator and it computes the digest locally via the Web Crypto API. The file is read from disk into the page — it is never uploaded, so this works fine for private builds and confidential documents. If the publisher only offers an MD5 sum, the MD5 Hash Generator covers that case.

On the command line, if you prefer:

# macOS / Linux
shasum -a 256 ubuntu-24.04.iso
sha256sum ubuntu-24.04.iso          # Linux coreutils
md5sum ubuntu-24.04.iso             # when the publisher only lists MD5

# Windows PowerShell
Get-FileHash -Algorithm SHA256 .\ubuntu-24.04.iso
Get-FileHash -Algorithm MD5 .\ubuntu-24.04.iso

If the publisher shipped a SHA256SUMS file, Linux and macOS can check every listed file in one shot:

sha256sum -c SHA256SUMS --ignore-missing

That prints OK per file and exits non-zero if anything fails — the least error-prone option when it is available.

Step 3: Compare the Two Values Exactly

This is the step people get wrong, and it is the step that matters.

Do not skim the two strings. Do not check that they "start with 2cf2 and end with 9824." A 64-character hex string is specifically designed to be unpleasant for a human to compare, and the failure mode of a quick visual check is a false match — precisely the outcome an attacker wants.

Paste both values into the Hash Comparison & File Integrity Verifier. It normalizes case and whitespace, does an exact character-by-character comparison, and gives you an unambiguous match or no-match. Case does not matter for hex digests — A3F and a3f are the same bytes — but nothing else is negotiable.

If they match, the file is identical to the one that was hashed. If they do not, stop. Re-download from the primary source, confirm you are comparing against the right platform build and version, and only then consider whether something worse happened.

What a Match Actually Proves

A matching digest proves integrity: the bytes did not change between the publisher hashing them and you hashing them.

It does not prove authenticity on its own. If an attacker controls the page serving both the file and the digest, they can swap the file and publish a matching digest for their version. That is why signed checksums exist: a GPG signature over the SHA256SUMS file, or an HMAC computed with a shared secret, ties the digest to someone who holds a key. The difference between "nothing changed" and "this came from who I think it did" is exactly the subject of HMAC vs Plain Hashing, and it is worth understanding before you rely on a bare checksum for security rather than for corruption detection.

CRC32 vs SHA-256: Not the Same Job

You will still run into CRC32 in zip archives, Gzip trailers, PNG chunks, and network protocols. It is worth being precise about what it is for.

	CRC32	SHA-256
Output	32 bits (8 hex chars)	256 bits (64 hex chars)
Designed for	Detecting accidental corruption	Resisting deliberate attack
Speed	Extremely fast	Fast, but slower
Forging a match	Trivial — seconds by hand	Infeasible

CRC32 is an error-detecting code, not a cryptographic hash. It reliably catches the random bit flips that storage media and noisy links produce, which is why archive formats embed it. But constructing a different file with the same CRC32 is elementary arithmetic — there is no security in it whatsoever. The CRC32 Checksum Generator is the right tool when you are validating an archive's internal checksum or matching a legacy system's expectations. It is the wrong tool for verifying a download you care about.

The same caution applies in weaker form to MD5 and SHA-1. Both remain useful for detecting accidental corruption, but both have lost collision resistance, so a match does not rule out a deliberately crafted substitute. Hash Collisions Explained covers how those attacks work and why an old digest algorithm can still be fine for one job and useless for another.

Common Reasons a Checksum Fails

• Truncated download. Interrupted transfers are the single most common cause. Check the file size against the published size first — it is a faster signal.
• Wrong file. Comparing the ARM build's digest against the x86 download, or last week's release against this week's.
• Wrong algorithm. Hashing with SHA-256 when the published value is SHA-1, or vice versa. Count the characters.
• Copy-paste damage. A trailing space, a line break inserted by a PDF or a chat client, or a leading * from a sha256sum output line. The comparator tool handles most of this, manual eyeballing does not.
• Text-mode transfer. An FTP client in ASCII mode rewriting line endings will silently change every byte of a binary file's digest.

Build It Into the Habit

Verification is only useful if you actually do it, so make it cheap. Keep the hash generator and comparator open in a tab when you are pulling releases. Prefer publishers who ship signed SHA256SUMS files, and use sha256sum -c when they do. Reserve manual comparison for the cases where you have no other option — and even then, paste rather than squint.

The whole routine is: note the algorithm, hash your copy, compare exactly, and treat any mismatch as a hard stop. Thirty seconds against the alternative of running a binary you cannot vouch for.