File Checksum Calculator
Compute a file's SHA-256, SHA-384, or SHA-512 checksum and compare it against the value the publisher listed.
Drop files here, or choose them
Any file type, any size · hashed on your device, never uploaded
A whole sha256sum line, a SHA256 (file) = … line, an sha256: prefix or a bare digest in hex or base64 all work — the digest just has to be in there
somewhere.
A checksum is a short fingerprint of a file's exact bytes. Change one byte anywhere — a truncated download, a corrupted USB copy, a tampered installer — and the fingerprint changes completely. That is why projects publish a checksum next to their download links: it lets you confirm that the file that reached you is the file they released.
This tool computes the three SHA-2 checksums in current use, plus the two older ones you still meet on download pages, SHA-1 and MD5. SHA-256 is by far the most widely published and the right default; SHA-384 and SHA-512 produce longer digests (48 and 64 bytes against SHA-256's 32) and are what you will see on some Linux distributions and in Subresource Integrity attributes. Any of the three SHA-2 sizes is a sound integrity check — the only reason to pick one over another is to match the value the publisher gave you.
How to verify a download
Drop the file in, paste the publisher's checksum into the expected-checksum box, and read the
badge. A green Checksum matches means the digest of your copy appears verbatim in
what you pasted, so you can paste the whole line from a SHASUMS256.txt file
rather than picking the digest out of it by hand. The tool accepts the shapes checksums
actually arrive in: a bare digest, sha256sum output
(<digest> filename), the BSD form SHA256 (file) = <digest>, a sha256: prefix as Docker prints,
and base64 as used in an integrity="sha256-…" attribute. Upper-case hex matches
too — Windows' certutil and 7-Zip both print it that way.
If the digest of a 3-byte file containing abc is what you want to check the tool
itself against, SHA-256 gives ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad — that value is published in the SHA-2 standard itself, and it is one of the vectors this
tool's tests assert against.
Nothing is uploaded
The file never leaves your device. There is no upload, no request, and no server involved: the page reads the file with the browser's own File API and hashes it in a Web Worker on your machine. That is also why it works offline, and why the size of the file is limited only by how long you are willing to wait. Because the file is read in 4 MB slices rather than loaded whole, memory use stays flat whether you hash a 2 kB text file or a 4 GB disk image.
What MD5 and SHA-1 are for, and what they are not for
Both are broken in the sense that matters most: it is computationally practical to construct two different files that share one digest. MD5 collisions are trivial now, and SHA-1 collisions have been demonstrated since 2017 and only get cheaper. So a match on either tells you a download was not accidentally corrupted — a truncated transfer, a bad USB copy — and it cannot tell you that nobody swapped the file deliberately. For that you need SHA-256 or better.
They are here anyway, because plenty of older release pages, mirror listings and vendor downloads published nothing else, and a checksum you cannot compute is a checksum you cannot check. Matching the value someone published years ago is a legitimate job; treating that match as proof of authenticity is not. The tool says as much next to the algorithm buttons whenever one of the two is selected. If a publisher offers a SHA-256 line as well, use that one.
One trap worth knowing if you reach for SHA-1: a git object id is not a plain SHA-1 of
the file. Git hashes the bytes blob <length>\0 followed by the
content, so git hash-object and this tool disagree by design — for a file
containing hello and a newline, git reports ce013625030ba8dba906f756967f9e9ca394464a where a plain SHA-1 is f572d396fae9206628714fb2ce00f72e94f2258f.
Checksums are not passwords
SHA-2 is the right tool for fingerprinting a file and the wrong one for storing a password. These functions are built to be fast, which is a virtue when you are hashing a disk image and a liability when an attacker is guessing passwords billions of times a second. Password storage wants a deliberately slow, salted algorithm — bcrypt, scrypt or Argon2.
To hash typed text rather than a file, use the Hash Generator. For base64 encoding and decoding on its own, see the Base64 Encoder / Decoder, and for inspecting signed tokens the JWT Encoder / Decoder.
How do I check a downloaded file against a published SHA-256 checksum?
Drop the downloaded file into this tool, leave the algorithm on SHA-256, and paste the published checksum into the expected-checksum box. If the badge says the checksum matches, your copy is byte-for-byte identical to the released file. You can paste the whole line from a SHASUMS256.txt file — the digest only has to appear somewhere in the text.
Is my file uploaded anywhere?
No. The file is read from disk by your browser and hashed in a Web Worker on your own machine. This tool makes no network requests with your data, and it works offline once the page has loaded.
Can I compute an MD5 or SHA-1 checksum?
Yes, both are in the algorithm list, because a lot of older release pages and vendor downloads published nothing else and a checksum you cannot compute is a checksum you cannot check. Be clear about what a match proves: collisions are practical to construct for MD5 and demonstrated for SHA-1, so a match rules out accidental corruption but not deliberate substitution. If the publisher offers a SHA-256 line too, use that one.
Why does the SHA-1 here not match my git commit or object id?
Because a git object id is not a plain SHA-1 of the file. Git hashes the bytes "blob <length>\0" followed by the content, so the two differ by design — for a file containing "hello" and a newline, git hash-object reports ce013625030ba8dba906f756967f9e9ca394464a while a plain SHA-1 of those bytes is f572d396fae9206628714fb2ce00f72e94f2258f. To reproduce a git object id you need git, not a checksum tool.
Which should I use — SHA-256, SHA-384, or SHA-512?
Whichever one the publisher used, since you are comparing against their value. With no constraint, SHA-256 is the standard choice and produces a 64-character hex digest. SHA-512 produces a 128-character digest and can be slightly faster on 64-bit CPUs; SHA-384 is SHA-512 truncated to 96 hex characters, and turns up mainly in Subresource Integrity attributes.
How large a file can it handle?
There is no fixed limit. The file is read in 4 MB slices and hashed incrementally, so memory use does not grow with file size — a multi-gigabyte disk image works. What grows is time, which is why there is a progress bar and a cancel button.
Can I check several files at once?
Yes. Drop or pick as many as you like; they are hashed one after another so a single large file cannot be starved. Each row shows its own digest, and if you have pasted an expected checksum every row is compared against it — a quick way to find which of several files is the one you were given a checksum for.
Why do two tools give the same file different checksums?
For the same algorithm they should not — SHA-256 of a given file is a single well-defined value. In practice the usual causes are comparing digests from different algorithms, comparing a hex digest against a base64 one, or a text editor having rewritten line endings or added a trailing newline, which genuinely changes the file. Switch this tool to the encoding your other value is in and compare again.
What is the difference between a checksum and a hash?
In everyday use they mean the same thing here. Strictly, "checksum" covers any short value derived from data to detect corruption — including weak, fast ones like CRC32 — while a cryptographic hash such as SHA-256 is additionally built to make deliberate collisions infeasible. For verifying a download you want a cryptographic hash, which is what this tool computes.