Work out a file's SHA-256 and SHA-1
Works out the SHA-256 and SHA-1 of a file in your browser, using the machine's own cryptographic library, and checks them against a checksum you paste in. The file is read in this tab and never sent anywhere.
Any file, up to 512 MB. It is read in this tab and never sent anywhere.
Results are provided as-is, with no warranty of accuracy. The method and its sources are published below so you can check the working.
How it works
What this does
Answers one question: is the file on your disk the same file the publisher released? A checksum is a short fingerprint of every byte, so if yours matches theirs the download arrived intact, and if it does not then something between the two of you changed it — a truncated transfer, a bad mirror, or somebody interfering.
The file never leaves this tab. That is the point rather than a feature: a tool that answered “can I trust this file?” by uploading the file somewhere would be answering a different question badly.
The method
The digests are not computed by this page. They come from crypto.subtle, the
browser’s own cryptographic implementation — BoringSSL in Chrome, NSS in
Firefox, CommonCrypto in Safari — which is the same code the rest of your
machine already relies on. Writing SHA-256 out by hand here would produce a
smoother progress bar, run a good deal slower on a large file — the native code
is compiled, and reaches whatever SHA instructions the processor has — and add a
second implementation of a standard that has to be exactly right or the tool is
worse than no tool at all.
The cost of that choice is worth stating, because it is visible. Web
Cryptography exposes a one-shot digest, with no update-and-finalise pair, so
the work cannot be broken into pieces. The bar therefore moves once per
algorithm rather than by bytes, and the whole file has to be held in memory
while it is hashed, which is where the 512 MB limit comes from.
Comparison is deliberately forgiving about everything except the digest itself.
The same checksum is published as e3b0c442…, as SHA256: E3B0C442…, as
e3b0c442… ubuntu-24.04.iso on a line lifted out of a SHA256SUMS file, and as
e3 b0 c4 42 … by several desktop tools. Rejecting three of those on a
technicality would be this page telling somebody their correct answer is wrong.
A paste that is neither 64 nor 40 hexadecimal characters after that tidying is
reported as not being a checksum at all, rather than as a mismatch — a
half-copied string is the common mistake, and “does not match” is how somebody
deletes a download that was fine.
Before you read on
The checksum file this tool offers puts two spaces between the digest and the filename. What happens if there is only one?
sha256sum -c rejects the line as improperly formatted. The two spaces are not decoration: coreutils writes the digest, one separating space, then a mode character — a space for text, an asterisk for binary — and then the name. Drop one and there is no mode character, so the line does not parse. Somebody at a terminal reads that complaint as the download being bad. The comparison box on this page goes the other way and is deliberately forgiving — it accepts the digest bare, prefixed with SHA256:, in capitals, pasted as a whole SHA256SUMS line, or spaced into byte pairs the way several desktop tools print it — because rejecting a correct answer on a technicality is how somebody deletes a file that was fine.
A worked example
A file called notes.txt containing the three bytes abc:
SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-1 a9993e364706816aba3e25717850c26c9cd0d89d
Bytes 3
and the SHA-256 checksum file it offers, which is one line, with two spaces between the digest and the name:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad notes.txt
Those are the published vectors for the message abc, typed out by hand rather
than produced by the code. Worth being exact about where they come from, since
the obvious guess is wrong: FIPS 180-4 contains no test data at all, and its
Appendix A.2 is a one-line pointer to NIST’s Examples with Intermediate
Values, which is where both digests are worked through block by block. RFC 3174
carries the SHA-1 figure a second time, in the test driver in section 7.3.
The test file asserts both, along with the empty message, the 56-byte vector that catches a padding mistake, and the one-million-byte case — that last one from RFC 3174’s test driver for the SHA-1 and from Appendix B.3 of FIPS 180-2, the last edition of the standard to print examples, for the SHA-256. So if this page and the code ever disagree about what the tool does, the build fails.
The two spaces are not decoration. One space is what sha256sum -c reports as
improperly formatted, and that reads to somebody at a terminal as the checksum
being wrong.
What it does not do
It does not tell you a file is safe. A matching checksum proves the bytes are
the ones whose checksum you compared against, and nothing more; if the checksum
came off the same page as the download, anybody able to change one could change
the other, and only a signature checked against a key you already held answers
that. It does not verify signatures, and it does not offer MD5, because the
browser does not implement one. It does not hash a folder, a drive or anything
over 512 MB, since the whole file is held in memory. And the upper-case setting
changes only the two figures shown on this page — the downloadable checksum
files are always written in lower case, which is what sha256sum produces.
A deliberate edit always changes the whole-file digest. A WAV trimmer can copy every retained sample byte unchanged and still produce a different checksum, because its new header, length fields and metadata-free container are different bytes. Compare checksums only when two files are meant to be identical.
The same boundary applies to an archive. Create a ZIP first and checksum the
finished .zip when two copies of the whole container are meant to match; hash
an extracted entry when the promise concerns that file alone. ZIP’s CRC-32 can
detect accidental entry damage, but it is not a replacement for a separately
trusted SHA-256.
How it is done
- Read the chosen file in this tab as raw bytes. Nothing is decoded, converted or altered, because a checksum is taken over the bytes exactly as they sit on disk.
- Hand those bytes to the browser's own Web Crypto implementation with the algorithm name SHA-256, and read back the 32 bytes it returns.
- Do the same again with SHA-1, which returns 20 bytes. Between the two the run hands control back so that Cancel works.
- Write each digest as lower-case hexadecimal, two characters per byte, keeping the leading zero on any byte below sixteen.
- Reduce the checksum you pasted to bare lower-case hex, dropping a "sha256:" label, surrounding whitespace, a trailing filename, or the spaces some tools print between byte pairs, then compare it against both digests.
- Offer each digest as a one-line file laid out the way sha256sum writes one, so that "sha256sum -c" reads it back without complaint.
What it assumes
- Both digests come from the browser's own Web Crypto implementation rather than from code on this page, so the figures are whatever the cryptographic library already on your machine produces.
- A matching checksum shows the file is byte for byte the one that was published. It says nothing about who published it, because anybody able to replace a download can replace the checksum listed beside it. Only a signature settles that.
- SHA-1 is here for checking against older published lists. Collisions have been demonstrated in practice since 2017 and NIST began retiring it in 2022, so a SHA-1 match is evidence against corruption rather than against tampering.
- The whole file is held in memory in this tab while it is hashed, which is why it is capped at 512 MB. Web Cryptography has no incremental digest, so there is no way to hash a larger file a piece at a time.
- The comparison ignores case, surrounding whitespace, an algorithm label and a trailing filename, because those are the shapes checksums are actually published in. It does not ignore anything inside the digest itself.
Common questions
Is the file I am hashing uploaded anywhere?
No. The file is read in this browser tab and hashed by a worker running on your own machine. There is no server to send it to, and the automated test for this page fails if any request leaves this site while a file is loaded. That matters more here than on most pages, because the reason to checksum a file is that you do not yet trust it.
Should I use the SHA-256 or the SHA-1?
Use the SHA-256 unless the checksum you were given is forty characters long, in which case it is a SHA-1 and that is the one to compare. Both are shown so you do not have to know which you were handed. If a publisher offers both, the SHA-256 is the one worth checking.
The checksum I was given is in capitals. Does that matter?
No. Hexadecimal has no case, and the comparison lower-cases both sides before looking at them. Spaces between byte pairs, a leading "sha256:" and a filename after the digest are all ignored as well, because published checksums come in all of those shapes.
The checksums do not match. What should I do?
Check the byte count first. If the size differs from the one the publisher lists, the download was truncated and simply needs fetching again, most often from a different mirror. If the size is right and the checksum is not, do not run the file. Fetch it again over a connection you control and compare once more before deciding anything.
Does a matching SHA-256 mean the file is safe?
It means the file is byte for byte the one whose checksum you compared against. It does not mean the publisher is honest, and it does not help if the checksum came from the same page as the download, because anybody able to replace one can replace the other. A detached signature checked against a key you already had is what answers that question.
Why is there no MD5?
Because the browser does not offer one. Web Cryptography registers four digest algorithms — SHA-1, SHA-256, SHA-384 and SHA-512 — and MD5 is not among them. Writing an MD5 by hand on a page whose whole job is producing a figure you can rely on is the wrong trade. If you have only an MD5 to compare against, use the md5sum or certutil already on your computer.
Why does the progress bar jump rather than creep?
Because Web Cryptography has no incremental digest. It takes the whole input and returns the whole result, with no point in between at which a fraction can be read, so the bar moves once per algorithm instead of pretending to measure something. The native implementation is fast enough that a 512 MB file is a second or two of work.