How to generate a SHA-256 hash on Mac

Almost every checksum you meet is a SHA-256, whether or not anything says so: 64 characters under a download link, a SHA256SUMS file beside an ISO, a form that wants the digest before it will accept your upload. On a Mac you can produce one in about ten seconds without opening Terminal — type the string into the Text tool or drop the file into the Files tool, then read the row labeled SHA-256 under the SHA-2 heading.

Producing it is the easy half. The half that costs people an afternoon comes afterwards: a string and a file are not the same input even when they hold the same words, and the 32 bytes you just copied get written down in at least four notations, only one of which looks like the hexadecimal on your clipboard.

Why almost everything asks for this one

SHA-256 was published in 2001, as part of the SHA-2 family, and it won by being good enough everywhere rather than best at anything. 256 bits is far more than any attacker can search. The arithmetic is cheap, and Apple Silicon runs the rounds in dedicated instructions — roughly 2 GB/s is representative, which means that on any real file the disk finishes last and the algorithm spends its time waiting. Nobody has to be talked into it, which is why it has become the thing people mean when they say “the checksum” with no further detail.

The other reason is negative: nothing has gone wrong with it. No two inputs with the same SHA-256 digest have ever been found, and nobody expects to find one. That is exactly the promise MD5 gave up in 2004 and SHA-1 gave up in 2017, and it is the promise you are relying on every time you treat a digest as the name of a file rather than as a rough error check. What broke in those two is collision resistance — the difficulty of constructing two inputs that share a digest — and not one-wayness: nobody can work backwards from an MD5 digest to its input. Corruption cannot construct anything, which is why MD5 still catches a damaged download; an attacker who can build a colliding pair is why it cannot prove a file is the file you were promised.

Two things SHA-256 is not for. It is not for storing passwords — being fast is the flaw there, and the longer explanation covers what belongs in that slot instead. And it is not a signature: it proves the bytes have not changed, never who produced them.

Generate a SHA-256 on your Mac

1. Decide whether you are hashing text or a file

   This decides which tool you want and it decides your answer. Hashing text covers exactly the characters you typed, UTF-8 encoded. Hashing a file covers every byte on disk, which for a one-line text file includes the newline at the end — so the two give different digests for what looks like the same content. Whoever published the checksum hashed the file.

2. For a string, use the Text tool

   Click Text in the sidebar and type or paste. The digests appear as you go, and SHA-256 is the first row under SHA-2. Click that row to copy the value. This side of the app is free, and hashing text on a Mac goes through what the byte count under the field is telling you.

3. For a file, use the Files tool

   Click Files, set the Algorithm control in the toolbar — the one marked with a # — to SHA-256, then drag the file in from the Finder or add it with the + button. The file becomes a row: its name, the folder it came from, its size, and the digest. The file is read exactly once and all eight digests come out of that single pass, so seeing all eight costs no second trip over the disk. Hashing a file covers the row in detail; the Files tool is one of the two one-time unlocks.

4. Copy the digest, never retype it

   Use the copy button on the row, or click the digest itself in the Text tool. Long values are shortened in the middle on screen to fit the row; what lands on the clipboard is all 64 characters. Retyping hex by hand is how a perfectly good file acquires a mismatch that takes an hour to explain.

How to read the 64 characters

Sixty-four hexadecimal digits, each one standing for four bits: 256 bits, 32 bytes, one digest. The count is fixed. An empty file and a feature film both come out at 64 characters, which is the property that makes a digest usable as a label.

There is no structure inside it to interpret. If yours starts with 0000 that is luck, not a flag, and a run of repeated characters means nothing at all. Digests are also case-insensitive as values but not as text: BA7816BF… and ba7816bf… are the same 32 bytes, and a script that compares them as strings will still tell you they differ. Tools on this site and on macOS print lowercase; some Windows utilities print uppercase. Lowercase everything before comparing and that whole class of problem disappears.

Then there is notation. The same 32 bytes get written down in several ways depending on who is doing the writing, and recognizing them saves you concluding that a digest does not match when in fact you are reading it in two different alphabets. Every row below is the SHA-256 of the three letters abc:

The third row is worth a second look. ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qctBD/YfIAFa0= is 44 characters with a trailing equals sign and not a hex digit in sight, and it is bit-for-bit the same digest as the first row — base64 packs the same 32 bytes more densely. If somebody sends you a checksum that looks like that, nothing is wrong and nothing needs converting; you simply have to compare like with like.

Writing a digest down so it is still useful next year

A bare 64-character string in a note is nearly worthless six months later, because you no longer know which file it described or which algorithm made it. Four fields fix that: the digest, the algorithm, the file name, and the size. The date helps too.

That is exactly the information a checksum manifest carries, which is why the two-column format — digest, then filename, one line per file — has survived unchanged for thirty years. Exporting one at the end of a run beats keeping notes by hand, and the result is readable by the command line tools on any operating system, including the ones your Linux colleagues have. Exporting a checksum manifest covers producing one and what to keep it next to.

Using the digest once you have it

A digest you generated and wrote down is only worth the note it is in if you can get a verdict out of it later, and that is a different job from producing it. 64 characters is the length at which eyes stop being reliable. The two ends are easy; the middle is where a transposed pair hides, and a mismatch found by squinting is not a finding so much as a suspicion.

Verify is the third item in the sidebar, and comparing is the whole of what it does. A segmented control offers two modes. Against a Checksum takes a file and a value: drop one into the well, paste the other, and the algorithm is read from the value itself, so 64 hexadecimal characters need no announcing. The answer appears underneath as a green seal and a sentence — yes or no, where reading two strings side by side only ever gets you as far as “I did not spot a difference”.

The other mode, File vs. File, is for when no digest was ever published: the copy that came off the server against the copy on your laptop, or last week's export against this week's. Two drop wells sit side by side with a swap control between them, and the verdict names the algorithm it compared with. Comparing two files directly goes through that mode and what it settles. Verification is one of the two one-time unlocks, separate from Files; hashing text is free whichever you buy.

Troubleshooting

My digest is 64 characters but does not match theirs

Then the bytes were not identical on both sides, whatever the two files are called. Check the file size against the one the publisher lists first — that catches truncated downloads in seconds. After that, check that you have the same build, the same architecture and not a (1) copy sitting in the same folder. When a checksum does not match works through the causes in order of likelihood.

The checksum I was given is 44 characters and ends with an equals sign

It is the same digest in base64 rather than hex. Nothing is wrong — you just cannot compare the two forms by eye. Ask for the hex form, or hash a known input in both notations to confirm they describe the same bytes.

There is a prefix, or spaces, in the value

sha256: and SHA256: are labels, not part of the digest, and some tools group hex into pairs separated by spaces or colons for readability. Strip the prefix and the separators and you have your 64 characters. If what remains is not 64 characters, you were handed a different algorithm: 32 means MD5, 40 means SHA-1, 128 means SHA-512 or SHA3-512.

I need one SHA-256 for a whole folder

There is no such thing as the SHA-256 of a folder — a hash function takes bytes, and a folder is a structure, not bytes. What you get is a digest per file, which is more useful anyway because it tells you which file changed. Hashing a folder explains the distinction and how to compare two folders properly.

It is taking much longer than I expected

Almost certainly not the arithmetic. A network share, a USB 2 enclosure, a spinning disk or a backup agent reading the same file at the same time will all dominate the time; SHA-256 itself runs faster than most drives can feed it. Copy the file to the internal SSD and hash it again: if it finishes in a fraction of the time, you were watching the storage, not the algorithm.

Frequently asked questions

How do I get the SHA-256 of a file on a Mac?

Drop the file into the Files tool with the Algorithm control set to SHA-256 and read the digest beside the file name — the file is streamed past once however many algorithms you asked for, and the copy button hands you all 64 characters. A 60 GB disk image is the same two gestures as a text file, and nothing leaves the machine. Reading a file is what the app is for; if what you need a digest of is a string rather than a file, the SHA-256 generator on this site hashes text as you type it in a browser tab, with nothing uploaded.

How many characters is a SHA-256 hash?

64 hexadecimal characters, which is 256 bits or 32 bytes. The length never varies with the input — an empty file and a 100 GB disk image both produce 64 characters. Other lengths mean other algorithms: 32 is MD5, 40 is SHA-1, 96 is SHA-384, 128 is SHA-512 or SHA3-512. The full table is in how long a SHA-256 hash is.

How do I get a SHA-256 for every file in a folder?

Drag the folder itself in rather than picking files out of it. Every file inside becomes its own row with its own digest, because a folder has no single SHA-256 of its own — a hash function takes bytes, and a folder is a list of names. The status bar counts them off as they finish, and the export button writes the whole set out as a two-column checksum file you can re-check later. Hashing many files at once covers the queue, including pausing a long run and resuming it.

Why is my SHA-256 different from the one on the download page?

Because you hashed different bytes. Check the file size against the published size first — an interrupted download is the commonest cause by a wide margin. Then check you have the same version and the same architecture, and that you are not hashing a duplicate copy or a partial .part file left in the same folder.

Can a SHA-256 hash be decrypted back to the original file?

No. SHA-256 is not encryption and there is no key: it reduces any amount of input to 32 bytes and keeps none of the rest, so a 4 GB installer can no more be rebuilt from its digest than a book from its page count. Sites advertising hash “decryption” hold a table of digests for short, common strings and look yours up in it — which is why no such site can offer you a file back.

Is uppercase SHA-256 the same as lowercase?

As a value, yes — hexadecimal is case-insensitive, so BA7816BF and ba7816bf are the same bytes. As text, no, which matters because a script comparing two strings will report a mismatch. Convert both to lowercase before comparing; macOS tools print lowercase already.

What is the sha256: prefix in front of some checksums?

A label naming the algorithm, used where a value has to be self-describing — container image references are the common example. Everything after the colon is the ordinary digest. A sha256- prefix followed by a string ending in = is the same idea in web page integrity attributes, except the digest there is written in base64 rather than hex.