Hash files with MD5, SHA-1, SHA-2 and CRC, and verify them against a published digest or a whole checksum file
Initializing in your browser…
MD5, SHA-1, SHA-2 and CRC digests of text or a file, with HMAC and verification against a published digest
Build a colour harmony that holds its lightness by rotating hue in OKLCH, with the contrast of every pair, a perceptually even tint and shade ramp, and what a colour blind reader sees
Decode a JSON Web Token and, given the secret or public key, actually verify its signature. Refuses alg: none and algorithm confusion
A project publishes a SHA256SUMS file and you want to know whether the four files you downloaded are the ones they released.
Loaded
SHA256SUMS (4 lines) plus alpha.bin, beta.bin, gamma.bin, dupe.bin
Result
alpha.bin OK (SHA-256) beta.bin OK (SHA-256) gamma.bin FAILED delta.bin file not provided Not named in the checksum file: dupe.bin
The checksum file is read in both the GNU "hash name" and the BSD "SHA256 (name) = hash" forms, and loading it turns on whichever algorithm its lines actually use. Every line is compared in constant time and reported as matched, failed or not provided, with any extra files listed separately. A single pasted digest works the same way in hex, base64, spaced or colon-separated form, with the algorithm worked out from its length.
Drop a file in and get its checksum, or paste the digest a project published and find out whether the file you downloaded is the file they released. Eight algorithms are available: MD5, SHA-1, SHA-256, SHA-384, SHA-512 and the non-cryptographic CRC-32, CRC-32C and Adler-32. Several can run at once over the same file. Nothing is uploaded; the file is read in the page and never leaves it. A matching digest tells you two different things depending on which one it is. Any of them proves the file was not corrupted in transit or on disk. Only a digest that is still collision-resistant, which today means SHA-256 or stronger, proves it was not swapped for a different file on purpose, and only if you got the published digest over a channel the attacker did not control. MD5 and SHA-1 are broken for collisions and CRC-32 is trivially forged, so those three are for spotting accidents. The tool labels each algorithm with which it is, next to the digest it produces, rather than leaving you to remember.
The tool has four modes. Calculate hashes one file and shows every ticked algorithm at once, with the file name, size, type and modified date alongside. Verify checks a file against something a publisher put on their site. Compare hashes two files and says whether they are byte for byte identical. Batch hashes a list of files, groups any that share a digest so duplicates fall out, and exports the result in the GNU `hash name` format that `sha256sum -c` reads back.
Verify accepts a digest in whatever shape you copied it. Bare hex, upper or lower case, with spaces or colons between the bytes, base64, a whole GNU line including the filename, or the BSD form `SHA256 (file) = ...` that macOS `shasum -p` prints. It works out which algorithm could have produced a digest of that length, tells you which one matched, and compares in constant time so the answer cannot be pulled out a byte at a time by timing. It also takes a whole checksum file: load a SHASUMS, .sha256 or .md5 file, add the files it names, and every line is checked and reported as matched, failed, or not provided, with any files you added that the checksum file does not mention listed separately. Loading a checksum file also turns on whichever algorithm its lines actually use.
File size is handled honestly. CRC-32, CRC-32C, Adler-32 and MD5 stream a chunk at a time and work at any size. Web Crypto, which is what makes SHA fast, has no incremental interface, so a SHA digest reads the whole file into memory up to a gigabyte and switches to a JavaScript streaming digest above that. The fast path runs at roughly 600 MB/s and the fallback at roughly 120 MB/s, and progress is reported from the bytes actually read rather than in two halves. A 2.5 GB file hashes in about a minute and matches openssl; a browser cannot read a file that size into a single buffer at all, which is what the older behaviour tried to do. Every run can be cancelled.
When Verify reports a mismatch the usual causes are, in order: the download is incomplete or corrupted, the digest was copied from a different release, a text file whose line endings changed when it was re-saved, or genuine tampering. The tool prints the digest it computed next to the one you pasted so the two can be compared by eye.
Switch to Verify, drop the .iso in, and paste the SHA256SUMS line from the project's HTTPS page. The tool works out the algorithm, compares in constant time, and prints the digest it computed next to the one you pasted.
In Verify, load the project's SHA256SUMS file, then add every file you downloaded. Each line is reported as matched, failed or not provided, and any extra files you added are listed separately.
Compare mode hashes both files and reports identical or different, useful for checking a backup copy is byte for byte the same as the original.
Confirm a downloaded ISO, installer or archive matches the digest the developer published, pasting their line exactly as it appears.
Load a SHASUMS file and the files it names, and see at a glance which lines matched, which failed and which files are missing.
Hash a file at both ends of an email or a cloud sync and compare, or use Compare mode on the two copies directly.
Batch mode groups files that share a digest, so identical copies under different names show up together.
Whichever the publisher used, which the tool works out from the digest you paste. If you are choosing, SHA-256. MD5 and SHA-1 are broken for collisions and CRC-32 is trivially forged, so those detect accidents rather than tampering, and the tool says so next to each one.
Yes. CRC-32, CRC-32C, Adler-32 and MD5 stream a chunk at a time at any size. SHA buffers the file up to a gigabyte, which is the fast path, and streams in JavaScript above that. A 2.5 GB file takes about a minute and the digest matches openssl.
Bare hex in either case, hex with spaces or colons, base64, a GNU checksum line such as "abc123... ubuntu.iso", and the BSD form "SHA256 (ubuntu.iso) = abc123...". Trailing whitespace and newlines do not matter.
This one is built around files: batch hashing, checksum-file import and export, duplicate detection and file comparison. The hash generator is built around typed text, with keyed HMAC and hex or base64 key handling.
No. It is read in the page through the File API and hashed there. Nothing is sent anywhere, which is also why a large file takes as long as your machine takes.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.