A software vendor posts a download link next to a string like a94a8fe5ccb19ba61c4c0873d391e987982fbbd3. That string is a checksum — and if you've ever wondered whether you're supposed to do anything with it, the answer is yes. Here's what a SHA-256 checksum actually is, when checking one matters, and how to verify a download's checksum in your browser.
What a checksum actually is
A checksum (also called a hash or digest) is the output of a cryptographic hash function run over a file's bytes. SHA-256 — part of the SHA-2 family, published by NIST — always produces the same 256-bit (64 hex character) output for the same input, and a single changed byte anywhere in the file produces a completely different output. That's what makes it useful for verification: it's not a summary of the file, it's a fingerprint of every byte in it.
Two properties matter here:
- Deterministic. The same file, hashed twice, always produces the same digest — on any machine, in any browser, with any implementation, because the algorithm is a fixed public specification, not something proprietary to one tool.
- Collision-resistant. Finding two different files that produce the same SHA-256 digest is, as far as anyone has publicly demonstrated, computationally infeasible. So a matching digest is strong evidence the bytes are identical, not just similar.
A checksum doesn't tell you a file is safe — malware can ship with a perfectly valid checksum for its own bytes. What it tells you is that the file you have is the exact file the checksum was computed from: nothing added, removed, or flipped in transit.
When to actually check one
Most downloads, most of the time, you don't bother. Checking a checksum earns its keep in a few specific situations:
- Installers and firmware. A corrupted download of an OS installer or a firmware image can brick a device or fail installation halfway through in a way that's hard to diagnose. Confirming the checksum before you run it catches that up front.
- Large file transfers. The bigger the file, the more likely a partial download or flaky connection leaves you with a truncated or corrupted copy. A checksum mismatch tells you immediately, instead of discovering it when the file won't open.
- Verifying nothing changed. If you need to prove a document or dataset is identical to a version you fingerprinted earlier — for an audit trail, a compliance record, or just your own peace of mind — comparing checksums over time does that without needing to diff the whole file by hand.
- Confirming a publisher's signature. Many open-source projects publish a
SHA256SUMSfile alongside their releases specifically so downloaders can verify integrity independently of the download mirror they used.
If the checksum you compute doesn't match the one the publisher listed, don't run the file. A mismatch means the bytes differ from what was published — from ordinary network corruption at best, to a tampered file at worst. Either way, re-download from the source rather than trusting it.
How to verify a checksum in your browser
FileX's file integrity tool computes cryptographic digests entirely client-side, using the browser's built-in Web Crypto API (crypto.subtle.digest) — the file is read locally and never uploaded anywhere:
- Open the integrity tool and drop in the file you downloaded.
- Pick an algorithm. SHA-256 is the most common for public checksums; SHA-384 and SHA-512 are also available for cases that call for a longer digest, and SHA-1 is offered only for comparing against older, legacy-published checksums — it's cryptographically broken for anything security-sensitive and shouldn't be trusted to detect deliberate tampering.
- Paste the checksum the publisher listed into the "compare against" field, and hit compute. FileX hashes the file locally and tells you outright whether it matches — no eyeballing a 64-character hex string for a typo.
If you need to fingerprint several files at once — say, an entire release directory — the tool's Manifest mode hashes every file you drop in and produces a downloadable SHA256SUMS-style checksum list in one pass, matching the format most open-source projects already publish.
Checksum vs. HMAC: when you need a shared key
A plain checksum verifies integrity — that the bytes weren't altered — but anyone can compute a SHA-256 digest of a file, including whoever might have tampered with it and then republished a matching checksum alongside it. If you need to prove the digest itself couldn't have been forged by someone without a shared secret, that's what HMAC (keyed-hash message authentication) is for.
FileX's integrity tool includes an HMAC mode: you supply a secret key alongside the file, and it computes a keyed digest via crypto.subtle.sign('HMAC', ...). Anyone verifying the HMAC needs the same key — so unlike a plain checksum, a valid HMAC also proves the digest came from someone who holds that key, not just from someone recomputing a hash after the fact. This is the same authenticated pattern that underlies how AES-256-GCM protects your files: encryption alone tells you a file is confidential, but an authentication tag (or here, an HMAC) is what tells you it hasn't been altered by someone without the key.
The short version
- A SHA-256 checksum is a deterministic fingerprint of a file's exact bytes — matching digests mean identical files, a mismatch means something changed.
- Check checksums for installers, firmware, large transfers, and anything you need to later prove wasn't altered.
- Use HMAC instead of a plain checksum when you need to prove the digest came from someone holding a shared key, not just anyone who recomputed a hash.
- FileX computes SHA-1/256/384/512 digests and HMACs entirely in your browser via the Web Crypto API — the file is read locally and never uploaded.
Have a download to verify? Compute its checksum now — nothing leaves your browser, and the live monitor on the page shows exactly zero bytes uploaded.