Verify a checksum

Drop a file, paste the hash the publisher listed, get a clear match or mismatch — free, private, in your browser. The algorithm is detected for you.

drop the file here or browse any size · read locally, never uploaded

waiting…

paste the expected hash and drop the file — in either order


How this works

Your file is hashed locally — read in 4 MB slices inside a background worker, so even a multi-gigabyte ISO streams through without uploading a byte or freezing the page. The pasted hash's length picks the algorithm: 32 hex characters means MD5, 40 means SHA-1, 64 means SHA-256 (or its same-length cousins SHA3-256 and BLAKE3 — the picker lets you switch), 96 SHA-384, 128 SHA-512. Messy pastes are fine: hash filename lines, SHA256 (file) = hash tag format, certutil's spaced pairs, uppercase, a stray 0x — all understood.

Where the expected hash comes from

The publisher's official page: a hex string beside the download link, a SHA256SUMS file on the release page, a "verify your download" section. Use the project's own site rather than a mirror when you can — the comparison is only as trustworthy as the place you copied the expected value from. Command-line folk can do the same check natively; guides for Windows, macOS and Linux.

If it doesn't match

In rough order of likelihood: the download is incomplete or corrupted (re-download; this fixes most cases); you're comparing against a different algorithm's hash (a 64-character value might be SHA3-256 or BLAKE3 — try the picker); the page listed the hash for a different build or architecture than the file you grabbed. If it still mismatches, treat the file as untrustworthy: don't run it, and fetch it from another official source. Checking a whole folder against a sums list? That's the batch tool.

What a match does and doesn't prove

A match proves the file is bit-for-bit identical to what the publisher hashed — transit corruption and swapped files are ruled out. It does not prove the publisher's copy was benign, and if attackers control the download page they'll list a hash matching their tampered file. That next level of assurance — who published it — is what GPG or minisign signatures add; background in what is a checksum.

questions

Where do I find the expected checksum?

On the project's official download page or release notes — a hex string next to the download link, or a file named SHA256SUMS. Prefer the project's own site over mirrors: the point is comparing against the publisher, not the middleman.

The hashes don't match. What now?

First re-download — most mismatches are truncated or corrupted transfers. Then check the algorithm: a 64-character expected hash could be SHA-256, SHA3-256 or BLAKE3, and the picker above lets you try each. If it still fails, don't run the file; get it from another official source.

How do you know which algorithm my hash is?

By length: 32 hex characters means MD5, 40 means SHA-1, 64 means SHA-256 (or SHA3-256/BLAKE3), 96 SHA-384, 128 SHA-512. When the length is ambiguous this tool assumes the most common option and lets you override — the same logic behind the hash identifier.

Can I verify a whole list of files at once?

Yes — the batch tool imports a SHA256SUMS-style file, hashes every file you drop, and shows a per-file pass/fail table. This page is for the single-file case.

Does a matching checksum mean the file is safe?

It means the file is bit-for-bit what the publisher hashed — no corruption, no swap in transit. It says nothing about whether that original is trustworthy, and if an attacker controls the download page they can publish a hash for their tampered file. For authenticity on top of integrity, projects use signatures (GPG, minisign).