Check a download against its published checksum
Choose a file in the panel above and its checksum comes back without the file going anywhere: it is read a few megabytes at a time and the arithmetic runs beside it in this tab. Paste the digest the download page published into the compare box and the algorithm is worked out from its length, so you never have to know whether it was SHA-256 or SHA-512. You get a plain answer about whether the file you have is the file they meant to give you. Text can be hashed here too.
Check a file against the checksum somebody published
Point this at a file you have just downloaded and it will tell you its checksum without the file going anywhere: the reading and the arithmetic both happen here, which is the only way a check on a four gigabyte disk image is a check rather than an upload.
The one to use unless something tells you otherwise. It is what almost every project publishes.
Text is hashed as UTF-8, which is what every command line tool means by the text of a string. A trailing newline changes the answer, which is the usual reason a digest you worked out here disagrees with one from a terminal.
Your file is not uploaded. It is read in slices straight off the disk by this page and the arithmetic runs beside it, so nothing here needs the whole file in memory and nothing here has anywhere to send it. A hash tells you whether two things are identical; it is not a password and it is not encryption, and putting one somewhere public tells nobody anything about the file it came from.
Hash generator, step by step
- Paste the checksum you were givenThe whole line as you copied it, filename and all. Its length says which of the four algorithms it is, so nothing has to be chosen by hand.
- Choose the file you downloadedAny size. It is read in slices rather than loaded whole, so a disc image is no different from a text file except in how long it takes.
- Read the verdictThe digest appears with a line saying whether it matches. If it does not, the download is damaged or it is not the file that checksum describes.
Why this had to be written out rather than handed to the browser
Browsers ship SHA-1, SHA-256, SHA-384 and SHA-512 in WebCrypto, and none of it can do this job. The digest function there is one-shot: it takes the entire message as a single buffer, and there is no update and finish pair anywhere in the platform. That is fine for a password or a short string and useless for the thing people actually want a checksum for, because it means holding every byte of a four gigabyte disc image in memory at once before any arithmetic starts. So the four algorithms here are written out longhand in the incremental form the specification actually describes: a running state, a block at a time, the length of the message written into the padding at the end. The file is read in slices off the disk and each slice is fed in as it arrives, so the whole file never exists in memory and the tab never stops answering. That runs in a background thread, which is why the progress figure moves. The arithmetic is checked against shasum, the tool that ships with macOS and Linux, on every build.
Almost every page that offers to hash something for you offers to hash a string. Type into a box, get a digest back. That is a useful demonstration of what a hash function is and it is not what anybody needs a hash for.
What people need one for is a file. You have downloaded an installer, a disc image or an archive, the page you got it from prints a long hexadecimal number underneath the link, and the question is whether the two agree. It is the one moment in ordinary computing where a checksum earns its keep, and it is precisely the moment a paste-a-string tool cannot help with, because the only way to hash a file on somebody else’s site is to send them the file.
Which is why the interesting part of this page is not the arithmetic. The arithmetic has been settled since 2001 and is in the browser already, in a form that happens not to be usable here. The interesting part is that a four gigabyte file can be read a slice at a time by a web page, hashed as it goes, and never leave the machine it is sitting on. Nothing is uploaded, nothing needs to be, and the progress figure you are watching is your own disk being read.
If the two numbers do not match, the boring explanation is nearly always the right one: the download did not finish, or it finished from a mirror that was serving an older build. Download it again before assuming anything more exciting. And if they do match, be clear about what you have learnt. You have proved your copy is identical to the copy the checksum was made from. Whether that copy was worth having is a different question, and the answer to it is a signature rather than a hash.
Questions
Which algorithm should I use?
Whichever the people who published the file used, which the compare box works out for you from the length of what you paste. If you are generating a checksum rather than checking one, SHA-256 is the answer. It is what almost every project publishes, it is supported everywhere, and nothing about it is in question. SHA-512 is a fine choice too and is often faster on a modern processor despite being wider.
Why is SHA-1 still offered if it is broken?
Because a great deal of the world still uses it and you will meet it. Git names every commit with one, and plenty of older download pages publish nothing else. What is broken about it is collision resistance. Somebody who wants to can build two different files with the same SHA-1, which matters enormously for a signature and not at all for spotting a download that arrived corrupted. Use it to check what a page gave you and never to prove that a file came from a particular person.
The digest here does not match the one my terminal gave me.
If it is a file, check you hashed the same file rather than a copy your operating system unpacked or quarantined. If it is text, the usual cause is a newline. Most command line tools include the trailing newline at the end of the line you typed, and the box on this page hashes exactly what is in it. Echo without the newline, or pipe from a file, and the two agree.
Does the file get uploaded?
No, and it could not be. The file is read in slices by this page and hashed in a background thread here, which is the only reason it can handle something measured in gigabytes at all. An upload of the size this page routinely handles would take minutes and would need somewhere to arrive, and no such place exists on the other end of this address.
What does a matching checksum actually prove?
That your copy of the file is byte for byte the file whose checksum was published. That catches a download that was truncated, a disk that garbled it, or a mirror serving something stale, which is what checksums are mostly for. It does not prove the file is safe, and it does not prove the people who published it are who they say they are. If somebody can change the file on the site they can change the checksum printed underneath. A signature is the tool for that question.
Other things here
There is a full list on the free tools page. They all work the same way: in the browser, with nothing to install.