How to verify a SHA-256 checksum on Mac

The string is sixty-four characters long, it is sitting in your clipboard, and the file it belongs to is in your Downloads folder. Open Verify, choose Against a Checksum, drop the file into the well and paste the string: the answer appears underneath as a sentence, and the length of what you pasted is enough to identify SHA-256, so there is nothing to select first.

That is the entire procedure, and it is not the interesting part. The interesting part is that published SHA-256 values arrive in about six different shapes, only one of which looks like the sixty-four lowercase characters the documentation promised. This page covers recognizing what you have been handed, what a match actually licenses you to believe, and the one other algorithm that produces strings exactly this long.

If you are not sure the value you are holding is SHA-256 at all, identifying a checksum by its length settles it in a glance. If you are verifying something you just downloaded and have not found the publisher’s value yet, verifying a download starts one step earlier than this page does.

What a SHA-256 match proves

SHA-256 takes an input of any size and returns exactly 256 bits: 32 bytes, written as 64 hexadecimal characters. A one-byte file and a 90 GB disk image both come out the same length, and the same bytes always produce the same value on any machine in any year. That determinism is the whole basis of the comparison.

Two separate guarantees sit behind a verification, and they get conflated constantly:

• Preimage resistance. Given only a digest, nobody can work backwards to a file that produces it. This is why publishing a checksum gives nothing away, and why “decrypting” a hash is not a thing that exists.
• Collision resistance. Nobody can find two different inputs that share a digest — not a specific pair, any pair at all. No SHA-256 collision has ever been produced.

When you check a download, the property doing the work is a close relative of the first: given this file and this published digest, could somebody construct a different file with the same 64 characters? That is a second-preimage problem, and it remains infeasible even for algorithms that are otherwise considered broken. It is why an MD5 somebody published in 2011 is still worth checking today.

Collision resistance is the stronger property, and it is the one that matters when whoever produced the file is the party you are worried about — an attacker who controls both files can prepare an innocuous one to be reviewed, published or signed while keeping a malicious twin with the same digest. MD5 lost that property in 2004, and SHA-1 lost it publicly in 2017, when a real pair of colliding files was demonstrated. SHA-256 has lost neither property, which is why it is the value you should want to see published. MD5 against SHA-256 has the side-by-side.

The shapes a SHA-256 value arrives in

All of these encode the same 32 bytes, or are not a file digest at all. Work out which one you have before you decide anything has gone wrong.

The prefixed form carries one trap worth knowing. A sha256: digest printed by a container registry identifies an image manifest rather than a file sitting on your disk, so hashing the layer you downloaded will never reproduce it. The prefix is honest about the algorithm and quiet about what was fed into it.

Verify a file against a SHA-256 string

1. Copy the value and nothing else

   Take the hexadecimal out of whatever wrapper it arrived in, dropping a sha256: prefix or a SHA256 (…) = header if there is one. A whole line out of a checksum file is fine as it stands; a value with a stray space in the middle of it is not.

2. Confirm it is 64 hexadecimal characters

   This takes two seconds and saves the most frustrating kind of mismatch. 64 characters, all of them 0 to 9 or a to f, is SHA-256. Any other length is a different function, and you will need to produce the matching one instead.

3. Hand the file and the string over

   In Verify, with Against a Checksum selected, drop the file into the well and paste what you copied. Check the name and size shown in the well — verifying the installer you downloaded last month, which is still in the same folder, is a common and thoroughly confusing mistake.

4. Read the sentence

   The file is read once and the verdict appears below as plain English with a green seal behind it, rather than as two hex strings for your eyes to diff. There is no near-miss to interpret: flipping one bit of a file flips about half the bits of its digest, so almost every character comes out different.

If the answer is not the one you wanted, the cause is usually mundane and it is usually the file rather than the string — what to do when a checksum does not match runs through the causes in the order they actually occur.

The other algorithm that is 64 characters long

SHA3-256 produces digests of exactly the same length as SHA-256 and completely different contents, because the two are unrelated constructions that happen to output 256 bits. Nothing about a 64-character string tells you which of the two made it.

In practice this is rarely your problem: published download checksums are SHA-256 in the overwhelming majority of cases, and a publisher who uses SHA-3 almost always labels it. But if a 64-character value refuses to match and you have ruled out the file, it costs nothing to produce the file’s SHA3-256 and look. In the Files tool, a file row’s disclosure chevron expands every algorithm for that file, SHA3-256 among them, and the file is read only once, with every one of those digests coming out of that single pass. SHA-2 against SHA-3 explains why two functions with the same output size are not interchangeable.

Checking that a tool is telling the truth

Any implementation of SHA-256 that disagrees with these two values is broken, and they are the quickest way to satisfy yourself that whatever you are using is not:

• The digest of no input at all is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
• The digest of the three characters abc is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

Both come from NIST’s own test vectors and both are reproducible anywhere, which makes them a useful smoke test when two machines disagree — checking that a hashing tool is correct has a couple more known answers and takes about thirty seconds. Note the first value while you are here: an empty digest turns up more often than you would think.

What the window can know, and what it cannot

The verdict arrives as a sentence with a green seal rather than as two strings to diff, which matters because the failure mode of comparing hexadecimal by eye is that you stop reading carefully around the twelfth character. What it asserts is exact and also narrow: these bytes, in this file, produced the digest you pasted. Two things it cannot know follow from that, and between them they account for most mismatches on files that are perfectly sound.

• It cannot tell you which algorithm the publisher meant. Length is the only clue a bare hex string carries, and 64 characters is shared by SHA-256 and SHA3-256, so a SHA3-256 value pasted in place of a SHA-256 one just fails against a sound file.
• It cannot tell you the file is the one you meant. That is what the name and size in the drop well are for. A second copy with a (1) in its name verifies just as obediently against the wrong value.

There is also the case where the value you hold is not a digest of a whole file at all: a sha256: identifier out of a container registry, an integrity value covering an unpacked stream rather than the archive you downloaded, or a digest of a different edition of the same release. Each produces a confident no-match against a file that is entirely sound, and the answer is to go back for the right value rather than to download the file again.

When you have several files and one list

Checking against a pasted string is a one-file, one-value operation, and a release with eight files and a SHA256SUMS beside it is a different shape of job.

Put the files in the Files tool instead, with the Algorithm control set to SHA-256, and drag the folder in. Every file becomes a row: the name in bold, the folder it came from beneath it, the size, the SHA-256 middle-truncated, and a copy button. The status bar keeps a summary on the left and progress on the right, and the disclosure chevron on any row opens that file’s other seven digests from the same single pass over the bytes.

The export button then writes the run out as a shasum-compatible manifest, in the same two-column format the publisher’s list already uses — so the comparison becomes two text files side by side rather than eight pastes. Checking files against a manifest walks through that comparison.

Troubleshooting

The digest I got starts with e3b0c442

Then you hashed nothing. e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is the SHA-256 of zero bytes, so it means an empty text field, a zero-length file, or a placeholder that a failed download left behind. Check the size of what you pointed at before you look anywhere else.

It is 64 characters and it still does not match

Work through the file rather than the string, because the file is nearly always where the difference is. Did you hash the archive or something you unpacked out of it? Is this the build for your architecture? Is there a second copy of the download in the same folder with a (1) in its name? Only after all of that is it worth suspecting SHA3-256 or the value itself.

The publisher only published a SHA-512

Then produce a SHA-512, because you cannot convert between the two — a 128-character value is a different function’s output, not a longer version of a 64-character one. Asking for the longer digest costs you nothing in waiting, because the file is streamed once whichever you choose. If the publisher lists both, reproduce either one and you have your answer.

I was only given the first twelve characters

Abbreviated digests are a Git habit, and they are not useless: agreeing on twelve hexadecimal characters is a one-in-281-trillion coincidence, which is perfectly adequate for catching a corrupted transfer. It is not adequate as proof against somebody deliberately aiming at a prefix, which is much cheaper work than a full collision. Ask for the whole value when the answer matters.

The file is large and this is taking minutes

The arithmetic is not what you are waiting for: SHA-256 moves at roughly 2 GB/s on Apple Silicon, so on anything short of a fast internal SSD the limit is how quickly the disk can hand bytes over. A verification reads the file exactly once and cannot read less than all of it, which means the only lever you have is where the file is sitting — copying a 60 GB image off a network share before verifying it is usually faster than verifying it in place.

Frequently asked questions

Is every SHA-256 checksum 64 characters long?

Yes, whatever it was computed from: SHA-256 always returns 256 bits, which is 32 bytes or 64 hexadecimal characters, so a single byte and a 90 GB disk image produce values of the same length. A 64-character value is not automatically SHA-256, though — SHA3-256 is exactly as long and entirely unrelated to it. How long a SHA-256 hash is has the lengths for every other algorithm.

Does capitalization matter when comparing a SHA-256 checksum?

No. Hexadecimal is a notation for bytes, and FF and ff are the same byte, so an uppercase value copied out of a Windows tool and a lowercase one out of a publisher’s checksum file are the same checksum. What does matter is spaces and line breaks in the middle of the value: those are characters that were never part of it, and they will defeat a comparison while looking like nothing at all.

Can two different files have the same SHA-256 checksum?

In principle yes, because there are infinitely many possible files and only 2^256 possible digests. In practice no pair has ever been found, and nobody expects one to be: 2^256 is a number with 78 digits, and there is no known method of searching it that beats luck. Every practical use of SHA-256 rests on that, including the certificate securing this page.

Is SHA-256 still considered secure?

Yes. No collision has been produced, no shortcut to reversing it is known, and it remains the default recommendation for integrity and for signatures. The algorithms that failed are MD5, where collisions became trivial in 2004, and SHA-1, where a real colliding pair was demonstrated in 2017. Both are still fine for detecting accidental corruption and unsuitable where an adversary is part of the picture.

What if the publisher only lists an MD5 instead of a SHA-256?

Check the MD5. Altering a specific existing file so that it keeps a given MD5 is a second-preimage problem, which remains infeasible, so the check still catches corruption and still catches a substituted file. What MD5 no longer resists is somebody crafting two files together from the start, so prefer SHA-256 whenever both are offered. Is MD5 still safe? draws the line.

Do I have to pick SHA-256 before I verify?

No. The algorithm comes from the checksum you paste, because the length settles it: 64 hexadecimal characters is read as SHA-256, 96 as SHA-384, 128 as SHA-512. There is no menu to get wrong, which also means the length is the one thing worth checking yourself — a 40-character value is a SHA-1 and will never match a SHA-256. If you want to watch the arithmetic happen before you trust it, the SHA-256 generator on this site hashes any text you type and will compare the result against a checksum you paste, with nothing uploaded — a file, rather than a string, is what the Verify tool is for.