File Hash Generator: Verify a SHA-256 Checksum

A file hash generator answers one question: is this the file the publisher actually shipped? You compute the file's digest, compare it with the one the publisher published, and if they agree the download arrived intact. The awkward part is that a publisher almost never gives you a single hash. They give you a file — usually called SHA256SUMS — that lists every artefact in the release.

That gap is where most online hash tools stop being useful, so it is worth knowing how to work with the checksum file rather than around it.

What a checksum does and does not prove

A hash is a fixed-length fingerprint of the file's bytes. Change one byte and the digest changes completely — there is no partial credit and no way to tell how close two files were. So a matching digest proves the file you have is byte-for-byte the file that was hashed.

It does not prove the file is safe. If the publisher's own download page was compromised, the checksum printed on that page was compromised with it. It does not prove authorship either. What it does prove is narrower and genuinely valuable: the transfer completed, and nothing rewrote the file on the way — a truncated download, a corrupt mirror, or something substituted by the network between you and the server.

That is why the check matters most for exactly the downloads you would least like to run blind: installers, disk images, firmware, and anything fetched from a mirror you do not control.

The artefact you actually have is a file, not a hash

Open a release page and you get something like this — the real output of the run described below:

9243cc39527c67cff94265dea73ee089c54115c5570216744f0a3e177d722234  plain.bin
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  empty.bin
6b1d4bfe25f0144686cade6a6f77f222e6ef929b949a9d688e418d56dd3af609  two words.bin

A checksum file with forty lines is normal. To use a single-hash checker you have to find the line whose filename matches your download, copy 64 characters, and paste them into a comparison box without dropping one.

That manual step is precisely where the tool sites leave a gap. MiniWebtool's SHA256 generator describes its own workflow as "Enter text or upload a file and optionally paste an expected hash", and its instructions say to "enter the expected SHA256 hash in the comparison field" — one hash, one field. Kilotoolkit's MD5 tool is more explicit still: its Checksum Comparator tells you to "paste the MD5 hash provided by your software vendor into the 'Expected Hash' box", and its FAQ answers "paste the hash from the developer's website into the comparator". Singular, both times. Devglan's file hash generator goes the other way and "auto-detects the hash algorithm during verification", which is genuinely convenient — but it still takes one digest, and it supports only SHA-256 and SHA-512.

None of the three accepts the file the checksums arrived in. The tool is fine and the workflow is still manual, which is the whole difference between a hash generator and a checksum verifier.

How to check a SHA-256 checksum in one pass

Paste the contents of the checksum file into the expected-checksums box, then drop the file you downloaded. Nothing is copied by hand, and the filename decides which line applies.

Measured on a 9,449,529-byte test file — deliberately 9 MiB plus 12,345 bytes, so the read ends part-way through its third 4 MiB slice rather than landing on a boundary — all five digests together took 955 ms. The same data at 12 MiB, an exact three chunks, took 1,274 ms for all five algorithms and about 220 ms for SHA-256 alone. The block quoted above is the output of that run, and feeding it back produced a match on every row.

The download is checkable too, which is the test a checksum file has to pass to be worth anything. Saving a single-algorithm result writes SHA256SUMS.txt in the coreutils format — the same shape sha256sum writes — and macOS's own verifier reads it back without complaint:

$ shasum -a 256 -c SHA256SUMS.txt
plain.bin: OK
empty.bin: OK
two words.bin: OK

Three lines, 232 bytes, and the file is machine-checkable on any Linux or Mac with no second tool involved. Asking for all five algorithms instead produces a 1,427-byte CHECKSUMS.txt of 15 lines in the BSD style, which names the algorithm on each line — the coreutils format cannot, because the algorithm is implied by the command you ran. Both formats read back into the tool correctly.

Reading the verdicts, including the one that is not bad news

There are three answers and only one of them means trouble.

• Matches — the digest your file produced is the one the block lists for it. The row also names the line it used, so a match in a forty-line file is auditable rather than asserted.
• Does NOT match — the block names this file and the digests disagree. The file is not the one that checksum describes. Do not run it; download it again from somewhere else.
• Not listed — the block does not mention this filename at all. This is common and usually harmless: releases often publish checksums for one artefact while you downloaded another.

The failure mode worth designing against is the false alarm. A hash copied off a web page is frequently a character or two short, and a tool that compares a 61-character string against a 64-character one will report a mismatch — telling someone their perfectly good download is corrupt, which is the worst thing this kind of tool can do. Paste a 61-character SHA-256 into this one and the row keeps showing the computed digest while the box reports the near-miss by name: "61 hex characters, which is not a known digest length — 64 would be SHA-256". That sentence is the difference between a visitor re-downloading a 4 GB image and a visitor fixing their paste.

The awkward cases that decide whether a tool is real

A file renamed by the browser on a second download is the case that catches naive implementations. Download the same installer twice and the second copy arrives as ubuntu-24.04(1).iso; a tool that matches strictly on filename now reports "not listed" for a file that is byte-identical. Matching by digest as well means it still verifies, and the row explains itself — it names the line it matched, notes that the line names a different filename, and says the file may have been renamed. Matching by filename alone and by digest alone are both wrong; it has to be filename first, digest second.

Two further cases are worth trying on any tool before you trust it. A zero-byte file has a published SHA-256 — e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, the FIPS 180-4 test vector — so a tool that errors or returns blank on empty input is not computing SHA-256. And filenames containing spaces are routine in installers: the format separates the digest from the name with two spaces, so a parser that splits on whitespace silently truncates the name and the file stops matching. A name like two words.bin has to survive the round trip, and it does.

Which algorithm, and why MD5 still appears

Use SHA-256 for anything new. MD5 and SHA-1 are broken for security purposes — practical collisions have been demonstrated since 2004 and 2017 respectively — so neither can prove a file was not deliberately crafted to carry a chosen digest. They remain entirely adequate for detecting a corrupted transfer, which is why vendors still publish them, and why a tool that computes only SHA-256 leaves you stuck when a download page offers nothing else. SHA-384 and SHA-512 are the same family and no weaker; SHA-512 is usually faster on 64-bit hardware, which is why it appears on large-file pages.

None of them belong anywhere near password storage. Fast hashes are the wrong primitive for that; bcrypt, scrypt and Argon2 are slow on purpose.

Why this runs in your browser

The two things people hash are files they just downloaded from a stranger and files they are about to send to someone else. Uploading either one to an online tool to find out whether it is trustworthy is a strange bargain, and the checksum file itself often reveals more about a release than you meant to publish.

Computing the digest locally avoids the question entirely. Reading the file in 4 MiB slices means the whole file never has to fit in memory — which is also why this does not use the browser's built-in crypto API, since that needs the entire file in a single buffer and would fail on a multi-gigabyte disk image. Peak memory stays flat as the file grows, and the progress bar moves because the reads are real. You can disconnect from the network after the page loads and the digests are still correct.

Wrapping up

Verifying a download is a two-minute job, and the only part that is easy to get wrong is the part the tool should be doing for you. Paste the checksum file the publisher gave you, drop the file you downloaded, and read the verdict: matched, mismatched, or not listed.

If a digest does not match, download from a different mirror before doing anything else with the file. If it matches, you know the transfer completed and the bytes are the ones that were published. That is a narrower claim than "this file is safe" — and it is the one a checksum actually supports.