SHA256 checksum

The hard part is the comparison, not the hash

Every checksum tool prints sixty-four hexadecimal characters. Almost none of them do the thing you actually came to do, which is decide whether those sixty-four characters are the same as the sixty-four the publisher listed. So the work gets handed back to your eyes: two dense strings of letters and digits, side by side in different windows, in different fonts, one of them possibly in capitals. What people do next is entirely predictable — they check the first few characters, check the last few, and call it a match.

That shortcut is exactly the wrong instinct. A checksum is not a fingerprint you can recognize from a corner of it; it is a value where changing one bit anywhere in the file changes roughly half of the output. Two files that share the first eight characters of their SHA-256 sum are not nearly the same file. They are unrelated files, and the shared prefix is a coincidence of the kind you would see once in four billion. Comparing all sixty-four characters is trivial work for a computer and genuinely difficult for a person, which is why the field for the publisher’s sum sits right under the file here, and why the answer is the word match or the words no match rather than a second string for you to squint at.

How to get a SHA256 checksum without opening a terminal

It would be dishonest to pretend otherwise, so here are the commands. On Windows, in PowerShell or Command Prompt, certutil -hashfile yourfile SHA256, or in PowerShell specifically Get-FileHash yourfile, which uses SHA-256 by default. On macOS, shasum -a 256 yourfile. On Linux, sha256sum yourfile. None of these need installing, all of them are faster than this page, and if you have a terminal open you should use them.

The question worth asking is not whether an answer exists but who that answer leaves out, and this one leaves out a great many people. A managed work laptop may have the terminal disabled by policy. A Chromebook does not ship those commands at all. A phone has no shell to type them into. And an enormous number of people who download software have never opened PowerShell, have no reason to learn it, and should not have to in order to answer a single yes-or-no question about a file sitting in their Downloads folder. Those people are currently pushed toward sites that ask them to upload the installer they were being careful about — which inverts the entire point of checking it.

Why the file is never uploaded, and how to prove it

This tool reads the file off your own disk in 256 KB slices and does the arithmetic in this tab. There is no endpoint here that accepts a file, so there is nothing to trust: the claim is a property of the page rather than a promise about it. You can confirm it in about thirty seconds by opening your browser’s network panel before you add the file and watching the request list stay exactly as long as it was while the checksum appears. The same check works on any site making the same claim, and the full walkthrough is here — it is a skill worth having, because this is a category where the claim is easy to make and rarely tested.

There is a second reason it matters here more than elsewhere. Uploading a file to have it hashed is slower than hashing it locally by a wide margin, since the bytes have to cross the network first. A site that asks you to upload a four-gigabyte ISO to compute a value your own machine could compute in twenty seconds is not solving a technical problem. It is solving a different problem, and the file is the payment.

Big files are the normal case here, and that shaped the code

Most people who verify a checksum are verifying a distribution image or an installer, so the interesting sizes are gigabytes rather than kilobytes. Browsers ship a fast cryptography engine, crypto.subtle, and it is not used on this page — for one specific reason. It has exactly one digest method, and that method takes the whole input at once. There is no way to feed it a file piece by piece, which means the entire file must sit in memory before the first byte is hashed. Measured in Chromium on this machine, that allocation succeeds at 1.5 GB and fails at 2 GB with an out-of-memory error, and a 3 GB file fails even earlier, when the browser is asked to read it into a buffer at all.

So the hash here is implemented by hand, in a form that can be fed a slice at a time. It is roughly ten times slower per byte than the built-in engine — SHA-256 runs at about 165 MB per second, SHA-512 at about 64, since SHA-512 works in 64-bit words that JavaScript does not have and has to simulate with pairs of 32-bit ones. In exchange, memory stays flat: peak usage measured between one and seven megabytes while hashing a 3 GB file, because only one slice exists at a time. That file took twenty seconds and produced a sum identical to the one shasum -a 256 produced from the command line. Ten times slower and able to finish beats ten times faster and unable to start.

Paste the sum in whatever form you found it

Publishers do not agree on a format, so the field accepts all of them. A bare sum, in capitals as certutil and Get-FileHash print it, or lowercase as the Unix tools do. A line from a SHA256SUMS file, with the file name after it and a star in front of the name for binary mode. The BSD form, SHA256 (file) = …, and OpenSSL’s slightly different SHA2-256(file)= …. A sha256: label in front. A sum a narrow terminal wrapped across two lines. Or the entire checksum file pasted in one go — in which case the line naming your file is picked out automatically, which saves the genuinely annoying task of finding the right row among eighty.

Whatever gets removed is stated rather than done silently, because a tool that quietly reinterprets your input can quietly reinterpret it wrongly. The most common failure is invisible: a zero-width character copied along with the sum from a web page, which makes a string that looks perfect fail to parse. When that happens the character is named and its position given, and if you meet the problem in other text, the invisible character finder shows every one of them. Comparing two versions of a longer document is a different job, handled by the text comparison tool.

What the algorithms mean, and why MD5 is missing

SHA-256 is the default because it is what almost every publisher lists, and it is the right choice unless you are told otherwise. SHA-1 is offered because older projects still publish it, though it has been broken since 2017 in the sense that two different files with the same SHA-1 sum have actually been produced. SHA-512 and SHA-384 are here because some distributions publish those instead. You rarely have to choose: paste the expected sum and the algorithm is set from its length, since 40, 64, 96 and 128 hexadecimal characters each belong to exactly one of them.

MD5 is deliberately absent. It is not in the browser’s crypto engine, and the reason is that it stopped being trustworthy a long time ago — deliberately colliding two files has been practical since 2004. An MD5 match still proves a download was not corrupted in transit, which is a real if modest use, but it no longer proves that nobody substituted the file on purpose. If a publisher offers both, take the SHA-256. If MD5 is all they publish, that is itself worth noticing. A 32-character sum pasted into the field above is recognized and explained rather than rejected as invalid, because it is not invalid — it is simply a question this page cannot answer.

A hash cannot be reversed, and there is no tool that does it

People search for ways to decrypt a SHA-256 sum, and the premise is mistaken in a way worth spelling out. A hash is not encryption, because encryption is designed to be undone by whoever holds the key. Hashing throws information away on purpose: any input of any length, a single letter or a forty-gigabyte disk image, comes out as the same sixty-four characters of output. There is no key that recovers the original, and there could not be, because countless different files map to any given sum. The only thing anyone can do is guess an input, hash it, and see whether the result matches — which is why sites that claim to “decrypt” hashes are really just looking your value up in a table of previously hashed common passwords.

That one-way property is exactly what makes the check on this page meaningful. Because nobody can work backwards from a published sum to a file that produces it, a matching sum is strong evidence that you hold the file the publisher signed off on. One caveat is worth carrying away: get the expected sum from the publisher’s own site over HTTPS, not from a mirror or a forum post. A checksum published beside a tampered file by whoever tampered with it proves nothing whatsoever, and that is the one way this check can be defeated.