SHA-256 vs SHA-512 — Differences and Which to Use

SHA-512 is not SHA-256 with a bigger safety margin bolted on. It is the same design compiled, so to speak, for a different word size: 64-bit arithmetic instead of 32-bit, twice the block, twice the internal state, and sixteen extra rounds. Everything people find surprising about the comparison follows from that one decision, including the fact that the longer digest is frequently the quicker one to compute.

This page is the mechanical comparison — what is actually different inside, what that does to speed, what the extra 64 characters cost you in daily handling, and which of the two to reach for. If your question is really “which algorithm should I be using at all”, the four-question version gets you there faster; if you already know you want the longer one and just need it produced, generating a SHA-512 on a Mac is the practical route.

The short answer

If you are checking against somebody's published value, use whichever one they published; the two are not interchangeable. If the choice is yours, SHA-256, because everything else in the world assumes it. If you genuinely want SHA-512's internals, the better pick is often SHA-384 — see the end of this page.

The same design at two word sizes

Both belong to SHA-2, published by NIST in 2001, and both work the same way: chop the message into fixed-size blocks, pad the last one, and push each block through a compression function that stirs it into a running state. The state at the end, written as hexadecimal, is the digest. The parts are simply bigger in one than the other.

Internal parameters of SHA-256 compared with SHA-512
	SHA-256	SHA-512
Word size	32 bits	64 bits
Block size	512 bits (64 bytes)	1024 bits (128 bytes)
Rounds per block	64	80
Internal state	8 × 32 bits = 256	8 × 64 bits = 512
Digest	64 hex characters	128 hex characters
Longest input it defines	About 2 exbibytes	Effectively unlimited

The round constants differ too — 64 of them derived from the cube roots of the first 64 primes in one case, 80 wider ones in the other — but that is bookkeeping, not a design change. Neither has the other's weakness, and neither has a structural advantage the other lacks, because structurally they are the same machine.

One thing that follows from the shared design is worth knowing before you treat the bigger number as insurance: a cryptanalytic result against the SHA-2 construction would very probably apply to both. Picking SHA-512 to hedge against SHA-256 breaking is hedging with a correlated bet. SHA-3's different construction is the uncorrelated one, which is why it exists.

Why SHA-512 is often the faster one

Count the work per byte instead of per block and the surprise disappears. SHA-256 spends 64 rounds on every 64 bytes: one round per byte. SHA-512 spends 80 rounds on every 128 bytes: five rounds for every eight bytes. So SHA-512 performs roughly 37 percent fewer rounds for the same quantity of data, and on a 64-bit processor each of those rounds costs about what a 32-bit round costs, because the registers are already 64 bits wide and the wider addition is a single instruction.

In plain software on a 64-bit machine that nets out at SHA-512 being somewhere around a third faster per byte than SHA-256. Which is the opposite of what everyone expects from a number twice the size, and it is the reason SHA-512 turns up inside key-derivation work where throughput matters.

Two things spoil the tidy conclusion. The first is hardware: modern processors carry instructions that implement SHA-256's round function directly, and where those are in play SHA-256 pulls ahead again by a margin no amount of round-counting recovers. The second is that on a Mac the question barely arises. SHA-256 alone runs at roughly 2 GB/s on Apple Silicon, which is more than most storage can supply, so a file hash finishes as fast as the disk can read — and the pair of them finish at the same time, because both are waiting on the same bytes. When hashing feels slow it is almost never the algorithm you chose.

The place the difference does show is many small inputs in memory: hashing a million short strings, deriving keys, signing records in a loop. There, and only there, is a benchmark worth running.

Is SHA-512 twice as strong?

It has twice the margin on paper, and the margin is not the part that is doing any work. Against an attacker searching for a collision, the effort scales as half the digest length — 128 bits for SHA-256 and 256 bits for SHA-512 — because of the birthday bound. Against an attacker trying to find any input matching a digest you publish, it is the full length: 256 bits against 512.

The lower of those figures, 128 bits, means 2 to the power of 128 attempts — a count with thirty-nine digits in it. No machine that exists or is on anybody's roadmap approaches it, and no known attack shortens it for either algorithm. When both numbers are unreachable, the one that is twice as unreachable is not protecting you from anything you were exposed to.

Quantum computing is the one place where the gap is sometimes claimed to matter, and it is worth being precise about. Grover's algorithm square-roots the work of a preimage search, which would take SHA-256's 256 bits down to about 128 — still comfortably out of range — and SHA-512's to 256. For collisions, the quantum speedups are weak and expensive enough that they change nothing practical. Nobody is recommending a move from SHA-256 to SHA-512 on quantum grounds, and the post-quantum standards NIST has published are signature and key-exchange schemes, not replacement hashes.

What 128 characters cost you

This is the part of the comparison that actually bites, and it is never in the specification sheets. A SHA-512 digest is 128 characters, which is wider than a terminal, wider than most email clients wrap at, and wider than a great many input fields.

It wraps, and wrapped hex breaks. Pasted into an email or a ticket, a 128-character value often arrives with a newline in the middle of it. The comparison then fails, and the failure looks exactly like a corrupted file.
Fields reject it. Schemas and forms built for a 64-character digest will not take it, and the wrong fix — trimming it to fit — produces a value no other tool will ever reproduce.
People cannot check it by eye. Nobody compares 128 characters visually; they compare the first six and the last six and declare victory. That works, but it means the extra length bought you nothing at the one moment a human was in the loop.
It narrows who can verify you. Publish only a 512-bit value and every reader whose habit, script or form expects 64 characters has a small problem to solve before they can check your file.

None of that is an argument against SHA-512 where something requires it. It is an argument against choosing it because bigger sounds better, which is the reason it usually gets chosen.

A thirty-second self-check

Hash the three letters abc and compare with the values NIST published, which have not changed since 2001 and never will. Any tool disagreeing with these is wrong, and that includes this site.

SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-512 ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
SHA-384 cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7

Look at the third one against the second. SHA-384 is SHA-512's engine with its output cut short, and yet cb00753f… is not the opening of ddaf35a1… — it shares nothing with it. The reason is that SHA-384 starts from a different set of initial values, so the two produce unrelated digests from the first block onward. This trips up people who assume a truncated hash is a prefix of the longer one. It never is. Try it in the SHA-512 generator and the SHA-384 generator if you want to watch both change as you type.

Which one to reach for

Reach for SHA-256 when you are publishing a checksum somebody else will check, when a value has to survive being pasted through email and chat, when the verifying end is a script, a form or a 32-bit device, or when you simply have no reason to do otherwise. It is the default, and being the default is a real technical property: it is the one everything can verify.

Reach for SHA-512 when a specification, a protocol or a procurement document names it, when the value you are checking against is 128 characters long, or when you are hashing enormous numbers of small inputs in 64-bit software and have measured the gain.

And consider that the honest answer is frequently neither. SHA-384 is SHA-512 internally — the same 64-bit arithmetic, the same 512-bit state, the same speed characteristics — with a 96-character output. Because the output is truncated, it does not leak its internal state the way SHA-256 and SHA-512 both do, so it is the better choice anywhere a digest sits next to a secret rather than next to a download. It is also the SHA-2 variant you meet throughout TLS and in certificates built on the 384-bit elliptic curves, where it is chosen to match P-384's security level rather than for the truncation.

Whichever you settle on, you do not have to settle once. In Rocket Hash both come out of one read of the file: hashing a 40 GB disk image for SHA-256 and SHA-512 together costs one pass over the disk, not two, so publishing both is cheaper than the argument about which to publish. In the Files tool that is what the disclosure chevron at the end of a file row is for: it opens the row out into every algorithm for that file, the 64-character value and the 128-character one stacked under each other where you can read both at once. The Algorithm control in the toolbar decides which of them the collapsed row shows, and therefore which one the row's copy button hands you, so you can keep SHA-256 as the one you read at a glance and still have SHA-512 a chevron away.

For a string rather than a file the free Text tool does the same without any decision at all: type, and both appear under the SHA-2 heading along with SHA-384, recomputing on every keystroke. Clicking a row copies that one digest; Copy All takes the whole labeled block, which is the form to paste into a release note when you have decided to publish both.

Troubleshooting

My SHA-384 is not the start of my SHA-512

It never will be, and nothing is broken. SHA-384 runs the SHA-512 compression function from a different set of initial values before truncating, so the two digests diverge from the first block. The only way to get a genuine prefix is to truncate a SHA-512 yourself, which gives you a value with no standard name that no other tool will produce.

It says SHA-512 but the value is 64 characters

Three possibilities, in order of likelihood: the label is wrong and it is a SHA-256; somebody truncated the digest to fit a field; or it is genuinely SHA-512/256, a standardized variant that runs SHA-512 and emits 256 bits. The last one is real but uncommon, and a plain SHA-256 will not match it even though both are 64 characters. If there is any doubt, ask for the file's SHA-256 and compare that instead.

My benchmark says SHA-256 is faster

Then believe your benchmark. Either your processor is accelerating SHA-256 in hardware, or your inputs are short: a message of a few dozen bytes fills one 64-byte SHA-256 block at 64 rounds, while the same message fills one 128-byte SHA-512 block at 80 rounds, so for tiny inputs the padding overhead hands the win back to SHA-256. SHA-512's advantage is per byte at volume, and it needs volume to appear.

One published sum matches and the other does not

Your file cannot be two different files at once, so the disagreement is in the published values rather than in your copy. Projects that generate SHA256SUMS and SHA512SUMS at different moments, or that respin a binary and refresh only one of the two, leave exactly this footprint. Fetch both files again from the same release directory, compare their timestamps, and believe the one the project signs.

SHA-512 is slower on this machine, not faster

Check the word size before you blame the algorithm. On a 32-bit processor every 64-bit addition and rotation has to be assembled out of pairs of 32-bit operations, which costs SHA-512 its round advantage and then some — expect roughly half the throughput of SHA-256 there. That is why 32-bit embedded targets and older firmware stay on SHA-256, and one more reason a 64-character value reaches more verifiers than a 128-character one.

Frequently asked questions

What is the actual difference between SHA-256 and SHA-512?

They are one design built to two sizes: SHA-256 works in 32-bit words on 64-byte blocks over 64 rounds and emits 64 hexadecimal characters, while SHA-512 works in 64-bit words on 128-byte blocks over 80 rounds and emits 128. Both are unbroken, so in practice the differences you will notice are the length of the value and how widely tools expect it, not how safe your file is.

Why is SHA-512 faster than SHA-256 if its digest is longer?

Because output length is not the thing being computed. SHA-512 consumes 128 bytes per 80 rounds where SHA-256 consumes 64 bytes per 64 rounds, so it performs about 37 percent fewer rounds per byte, and on a 64-bit processor each of those wider rounds costs roughly what a narrower one does. Processors with built-in SHA-256 instructions reverse the result, and when the bytes are coming off a disk neither algorithm is the limit.

Why do some projects publish both SHA256SUMS and SHA512SUMS?

Partly habit and partly courtesy: one read of a release can produce every digest at once, so publishing a second file costs almost nothing and lets people verify with whatever their tooling or policy expects. Pick either — they describe the same bytes, and checking one is not weaker than checking the other.

Should I use SHA-256 or SHA-512 to verify a download?

Whichever the publisher published, because a digest can only be compared with one from the same function. Where both are offered, SHA-256 is the better habit: it is the value other tools, scripts and forms expect, and 64 characters survive being pasted into an email without wrapping onto a second line.

Does a very large file need SHA-512 rather than SHA-256?

No. A digest is a fixed size whatever the input, so a 100 GB disk image gets the same 64 characters a one-line text file does, and nothing about a large file erodes the strength of the shorter hash. SHA-256 is defined for inputs up to about two exbibytes, which no file on your Mac is approaching.

If I have a file's SHA-512, can I work out its SHA-256?

Not without the file. A digest keeps nothing of the input beyond its own bits, so there is no calculation leading from one algorithm's output to another's, and cutting a SHA-512 down to 64 characters does not produce a SHA-256 either. The only route to a second digest is a second pass over the original data.

Is it a problem that a SHA-512 digest wraps onto two lines?

It is the most common practical annoyance with it. Wrapping itself is harmless, but a newline that gets copied along with the hex makes the comparison fail in a way that looks exactly like a corrupted file. Paste the value into a plain text field and confirm it is 128 unbroken characters before you conclude anything about your download.