What is a file checksum?

A checksum is the output of a hash function run over a file's raw bytes. For SHA-256, that output is always a 256-bit (64 hex character) digest. Any change to the file — even one flipped bit — produces a completely different digest, which is why checksums detect accidental corruption and deliberate tampering.

Why is SHA-256 preferred over MD5 or SHA-1 for checksums?

MD5 and SHA-1 are vulnerable to collision attacks — two different files can be crafted to produce the same digest. An attacker who can generate collisions can substitute a malicious file while preserving the original hash. SHA-256 has no known practical collision and is still considered secure for integrity checking.

Does a matching checksum prove the file is safe?

Not entirely. A matching checksum proves the file arrived intact and matches what the server published. It does not prove the server was legitimate or that the published checksum itself was not tampered with. For that you need a cryptographic signature (e.g., GPG) over the checksum, so you can verify authorship, not just integrity.

Why does the hash change when I add a newline to a file?

Hash functions are computed over every byte, including whitespace. A trailing newline character (0x0A on Unix, 0x0D 0x0A on Windows) is real byte content. A file with a trailing newline and the same file without one have different byte sequences and therefore different SHA-256 digests.

What is the difference between a checksum and a GPG signature?

A checksum tells you the file matches a known digest, but only if you trust the channel that delivered the checksum. A GPG (PGP) signature goes further: it uses asymmetric cryptography to prove that the person holding a specific private key signed the file or its checksum. If you verify the signature against a trusted public key, you have both integrity and authenticity — you know who released the file, not just what it contains.

How to Verify a File Checksum with SHA-256 (Step by Step, Every OS)

You download an OS installer, a firmware update, or a release archive. The project page shows a long string of hexadecimal characters next to the download link. That string is the SHA-256 checksum — and knowing how to verify it takes thirty seconds per download once you have done it once.

This guide walks through the exact commands on every major operating system, explains what checksums can and cannot prove, and covers the small pile of practical gotchas that make hashes mismatch when the file itself is fine.

What a Checksum Actually Is

A checksum is the output of a hash function applied to every byte of a file. SHA-256 always produces a 256-bit result — 32 bytes, written as 64 lowercase hexadecimal characters. The defining property of a good hash function is avalanche effect: changing even one bit of the input produces a completely different digest. A 4 GB ISO and the same ISO with a single corrupted sector will produce entirely different SHA-256 hashes.

This makes checksums useful for two things. First, corruption detection: if the download was truncated or a storage device flipped bits, the computed hash will not match the published one. Second, tamper detection: if a MITM or a compromised mirror replaced the file with a malicious version, the hash will not match — provided the attacker could not also change the published checksum on the source page.

One thing checksums do not provide: secrecy. A hash reveals nothing confidential about a file's contents, and it does not encrypt anything. Hash functions are a tool for integrity, not confidentiality.

Why SHA-256 and Not MD5 or SHA-1

MD5 and SHA-1 are still printed on many legacy download pages, but both have known collision vulnerabilities — meaning two different files can be engineered to produce the same digest. In 2017, the SHAttered attack demonstrated a practical SHA-1 collision. MD5 collisions are even cheaper to generate.

The consequence for integrity checking: an attacker who can generate collisions can craft a malicious file that has the same MD5 or SHA-1 as the legitimate file, making the checksum useless as a tamper detector. SHA-256 (part of the SHA-2 family) has no known practical collision attack and remains the standard recommendation for file integrity. SHA-3 and BLAKE3 are also safe choices, but SHA-256 is what you will encounter on the vast majority of download pages today.

Four-step guide to verifying SHA-256 checksums: Step 1 — Find the published checksum on the release page (.sha256 file or hex string next to download link); Step 2 — Run the OS command (Windows: CertUtil or Get-FileHash, macOS: shasum -a 256, Linux: sha256sum); Step 3 — Compare all 64 hex characters against the published digest (case-insensitive); Step 4 — If match: file is intact. If mismatch: re-download or investigate. — Four steps to verify any SHA-256 checksum on Windows, macOS, or Linux — commands included for each OS.

Verifying on Windows

Windows ships two built-in tools that compute SHA-256 without any additional software.

CertUtil (Command Prompt)

Open a Command Prompt (Win + R, type cmd, press Enter) and run:

CertUtil -hashfile C:\Users\you\Downloads\ubuntu-24.04.iso SHA256

CertUtil prints the digest across two lines with spaces between each byte pair. Strip the spaces mentally (or compare character by character) against the published checksum. The comparison is case-insensitive — a3f... and A3F... are the same digest.

PowerShell Get-FileHash

PowerShell gives cleaner output and is easier to script. Open PowerShell and run:

Get-FileHash C:\Users\you\Downloads\ubuntu-24.04.iso -Algorithm SHA256 | Format-List

The output is a single uppercase hex string on the Hash line. To compare it directly against a known value in one command:

(Get-FileHash .\ubuntu-24.04.iso -Algorithm SHA256).Hash -eq "PASTE_EXPECTED_HASH_HERE"

PowerShell returns True or False. This is the fastest way to do a verification in a script or CI pipeline on Windows.

Verifying on macOS

macOS includes both shasum and openssl in the base install.

shasum

Open Terminal and run:

shasum -a 256 ~/Downloads/ubuntu-24.04.iso

Output is the 64-character hex digest followed by two spaces and the filename. Copy the hash portion and compare it against the published value.

openssl

If you prefer OpenSSL (also pre-installed on macOS):

openssl dgst -sha256 ~/Downloads/ubuntu-24.04.iso

OpenSSL prefixes the output with SHA2-256(filename)= before the hash. The hash value itself is identical to what shasum would produce.

One-liner comparison on macOS

To verify and get a pass/fail result directly:

echo "EXPECTED_HASH  ~/Downloads/ubuntu-24.04.iso" | shasum -a 256 --check

Note the two spaces between the hash and the filename — that is the format shasum --check expects. It prints OK on success or FAILED on mismatch.

Verifying on Linux

Every mainstream Linux distribution ships sha256sum (from the GNU coreutils package):

sha256sum ~/Downloads/ubuntu-24.04.iso

When the project provides a checksums.txt or SHA256SUMS file listing multiple files and their digests, you can verify all of them at once:

sha256sum --check SHA256SUMS

Each line in SHA256SUMS must follow the format hash filename (two spaces). The tool prints OK or FAILED for each entry and exits with a non-zero status if any check fails — useful in shell scripts and CI pipelines.

How to Compare the Digests Correctly

The comparison is straightforward but worth stating explicitly: all 64 hex characters must match. The check is case-insensitive (a–f and A–F are equivalent in hex), but every character position must agree. A single transposed digit means either the file is corrupt or the published checksum was tampered with.

The most common source of human error is whitespace in a copied hash. When you copy a checksum from a web page, leading spaces, trailing spaces, or line breaks sometimes come along. Paste the value into a plain text editor first to confirm it is exactly 64 characters with no surrounding whitespace before comparing.

Checksums vs GPG Signatures: Know the Difference

A checksum tells you the file matches a known digest. But that guarantee is only as strong as the channel that delivered the checksum. If an attacker compromises the download server and replaces both the file and its listed checksum simultaneously, you would compute the correct hash for the malicious file and see "match" — because the expected value was also swapped.

A GPG (PGP) signature closes this gap. The release team generates a hash of the file, then signs that hash with their private key. You verify the signature against their public key — a key you obtained through an out-of-band channel (a key server, a HTTPS page on a separate domain, a trusted package manager). If the signature verifies against the correct public key, you have confirmed both:

Integrity: the file matches the digest that was signed.
Authenticity: the person holding that private key (e.g., the project maintainer) produced the release.

For high-stakes downloads — operating system images, security tools, wallet software — always prefer a GPG signature over a bare checksum. For everyday dependency verification where a compromised mirror is the main threat, SHA-256 is practical and sufficient.

Checksums for Text, JSON, and Snippets in the Browser

File checksums are the most common case, but sometimes you need to hash a text string, an API response body, or a configuration snippet to confirm it has not drifted from a known-good state. For those cases, the Hash Generator on this site lets you paste any text and instantly see its SHA-256 (and other) digests without leaving the browser. The computation runs entirely client-side — nothing is sent to a server.

One important distinction: the browser tool hashes the text content you paste, while CLI tools like sha256sum hash every raw byte of a file on disk, including file metadata bytes that may differ across platforms. Use the CLI tool for file verification; use the browser tool when the unit you are hashing is a string.

Subresource Integrity: Checksums in HTML

Web browsers implement a related mechanism called Subresource Integrity (SRI) that uses the same SHA-256 algorithm. When you load a script or stylesheet from a CDN, you can pin the expected hash in the HTML tag:

<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="
  crossorigin="anonymous"></script>

The browser computes the SHA-256 of the fetched resource and compares it against the value in the integrity attribute. If they do not match, the resource is blocked. Notice that the SRI hash uses Base64 encoding rather than hex — the format is sha256-<base64digest>. If you ever need to convert between the two representations or generate SRI hashes manually, the Base64 Encoder handles that conversion. SRI is essentially the same integrity guarantee as a CLI checksum, but enforced by the browser at load time against CDN-delivered assets.

Common Pitfalls That Cause False Mismatches

Trailing newline or CRLF vs LF

Hash functions operate on every byte. A file that ends with a Unix newline (0x0A) has a different digest than the same file ending with a Windows CRLF (0x0D 0x0A), and both differ from a file with no trailing newline at all. When hashing scripts, configuration files, or source code, confirm the line-ending convention matches what was used when the published hash was computed. Most binary file distributions (ISOs, executables) do not have this problem because they are not text files.

Hashing the wrong file

Double-check the exact filename. A partially downloaded file, a file named ubuntu-24.04.iso (1).iso by the browser, or a compressed archive that still needs extraction will all produce wrong hashes. Hash the exact file as downloaded, before unzipping or renaming.

JSON and config manifests: canonicalize first

If you are computing or verifying a checksum over a JSON file — say, a lockfile, a manifest, or an API response — whitespace differences and key ordering both change the digest. Two semantically identical JSON objects with different spacing or key order produce different SHA-256 hashes. Before hashing, canonicalize the JSON to a consistent form. The JSON Formatter can normalize indentation and key ordering so the checksum becomes reproducible regardless of which tool serialized the file.

Whitespace in a pasted checksum

Some download pages wrap the hash in a <pre> block with padding, or the browser selection picks up a leading space. If your comparison fails but you are confident the file is correct, count the characters in the value you pasted — it should be exactly 64. Any other length means stray whitespace, or you accidentally copied a SHA-1 (40 chars) or SHA-512 (128 chars) hash instead.

Quick Reference

OS	Command
Windows (CMD)	`CertUtil -hashfile file.iso SHA256`
Windows (PowerShell)	`Get-FileHash file.iso -Algorithm SHA256`
macOS	`shasum -a 256 file.iso`
Linux	`sha256sum file.iso`

Verify Text and Snippets Without the CLI

For any case where you want to hash a string rather than a file — confirming an API response body, checking a config snippet, or generating an SRI hash for a small inline script — the Hash Generator gives you SHA-256, SHA-1, MD5, and other digests in one click, entirely in the browser.