Drop a downloaded ISO, installer or archive and get its SHA-256, MD5, SHA-1, SHA-512, CRC32, SHA3-256 or BLAKE3 digest, then paste the checksum from the download page to see a clear match or mismatch. Files are streamed through a WebAssembly hasher in 8 MB slices, so a multi-gigabyte file hashes with flat memory use, live progress and a cancel button — and nothing is uploaded. Hashing text rather than a file? Use the Hash Generator, or the HMAC Generator when a secret key is involved. To check what a file actually is before trusting it, see our guide to magic bytes and file signatures.
File Checksum Verifier
Hash files of any size in your browser and compare against an expected checksum
Drop files here or click to selectAny size — files are read in chunks and never uploaded. Drop a .sha256 / .md5 / SHA256SUMS file too and it fills the expected box.
Algorithms
Changing the selection re-hashes finished files that are missing the new digest.
Frequently asked questions
Do my files get uploaded anywhere?
No. The file is read by your browser in 8 MB slices and fed to a hashing engine compiled to WebAssembly, all on your own machine. No part of the file — not even its name — is sent anywhere, and there is no signup. The only request the tool itself makes is a one-time download of the WebAssembly hashing code from this site, the first time you hash something; you can watch the Network tab in devtools to confirm nothing else goes out.
How can it hash files that are several gigabytes?
Instead of loading the whole file into memory, the tool asks the browser for one 8 MB slice at a time, feeds it into an incremental (streaming) hasher, then discards it. Memory use stays flat regardless of file size, and progress is reported after every slice so you can cancel at any point. The built-in Web Crypto API cannot do this because it only accepts a complete buffer, which is why this tool uses the hash-wasm library instead.
Which algorithms are supported, and which should I use?
CRC32, MD5, SHA-1, SHA-256, SHA-512, SHA3-256 and BLAKE3. Use whatever algorithm the publisher gave you — the tool guesses it from the length of the expected value and tells you. If you are choosing one yourself, prefer SHA-256 or BLAKE3. MD5 and SHA-1 are fine for detecting accidental corruption but are not collision-resistant, so they cannot prove a file has not been tampered with. CRC32 only detects transmission errors.
What formats does the expected checksum box accept?
A bare hex digest in any case with optional spaces, colons or dashes between bytes; a base64 digest (standard or URL-safe, with or without padding); a line copied from sha256sum, shasum, md5sum or openssl output such as "ba7816bf… ubuntu.iso" or "SHA256 (ubuntu.iso) = ba7816bf…"; or a whole SHA256SUMS-style file with many lines, in which case each file you drop is matched by name. Dropping a .sha256, .md5 or SHA256SUMS file onto the dropzone loads it into the box automatically.
A matching checksum means the download is safe, right?
A match proves the bytes you have are identical to the bytes the publisher hashed — it rules out corruption and truncation. It does not prove the publisher is trustworthy, and if the checksum was served from the same page as the download, an attacker who replaced one could replace the other. For that guarantee look for a PGP signature or a checksum published through a separate channel.
Get weekly dev tools and tips