How to generate a SHA-512 hash on Mac
A SHA-512 digest is 128 hexadecimal characters — twice the length of the SHA-256 everyone else asks for, and no harder to produce: in Rocket Hash it sits two rows below SHA-256, under the same SHA-2 heading. The question worth two minutes of your time is not how to make one, but whether anything improves when you do.
Nobody picks SHA-512 for the pleasure of it; something upstream picked it for you. A compliance profile that says 512 bits and means it. A checksum file called SHA512SUMS where you expected the shorter name. A signature header built on HMAC-SHA-512. The output is 128 hexadecimal characters — 512 bits, 64 bytes — and producing one on a Mac takes the same two clicks as any other digest: type or drop in what you are hashing, then read the SHA-512 row, third under the SHA-2 heading.
So the procedure is short. What follows is what nobody prints next to the checksum: what those extra 64 characters do and do not buy, where SHA-512 is genuinely required rather than merely bigger, and the practical friction of moving a 128-character string around without breaking it.
Publishing a SHA-512 for a download you share means most people will produce a SHA-256 instead and have nothing to compare it with, and you gain nothing they can use. Choosing an algorithm is four questions long and usually lands on SHA-256.
What SHA-512 actually is
Not SHA-256 run twice, and not SHA-256 with a longer output bolted on. It is the same family built around a wider machine: where SHA-256 works in 32-bit words, chews through 512-bit blocks and runs 64 rounds, SHA-512 works in 64-bit words, takes 1024-bit blocks and runs 80 rounds. The constants differ, the starting state differs, and the two produce completely unrelated digests for the same input.
The output is 128 hex characters, which looks like this — the SHA-512 of the three letters abc, a value NIST publishes as a test vector:
ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
Hash an empty input and you should get a digest starting cf83e135. Those two values between them are enough to tell you whether any tool claiming to do SHA-512 is doing it correctly, and the same trick works on this site’s in-browser SHA-512 generator — type the three letters into it and see whether the 128 characters above come back.
One relation is worth knowing: SHA-384 is this exact algorithm with a different starting state, its output cut down to the first 96 characters. It is not a weaker cousin of SHA-512; it is SHA-512 wearing a shorter coat, and that truncation gives it one property SHA-512 lacks, which comes up below.
Produce a SHA-512 digest
-
Choose SHA-512 in the tool you are in
For text, click Text and type — SHA-512 is the third row under SHA-2, after SHA-256 and SHA-384, and it keeps pace with your typing. For a file, click Files and set the Algorithm control in the toolbar to SHA-512, or leave it where it is and open the chevron at the end of a file’s row, which expands every algorithm computed from that single read of the disk.
-
Copy the whole thing, do not read it
A 128-character value does not fit in a row, so the middle is replaced with an ellipsis on screen. That is display only: clicking the row, or using the copy button beside a file’s digest, puts every character on the clipboard. This is the point at which SHA-512 stops being like SHA-256 — 64 characters is something you can sanity-check with your eyes, and 128 is not.
-
Check it survived the journey
Paste it where it is going and confirm it arrived as one unbroken run of 128 characters. Mail clients wrap long strings, chat apps insert soft breaks, and spreadsheets have been known to mangle anything that looks like a number. A digest with a line break in the middle of it fails every comparison, and the failure looks exactly like a corrupted file.
Whether the extra 64 characters buy you anything
For protecting a file’s integrity, honestly: no. The number that matters for a checksum is collision resistance, and it is half the digest length, because of the birthday bound — SHA-256 gives you 128 bits of it, SHA-512 gives you 256.
| Algorithm | Hex characters | Collision resistance |
|---|---|---|
| SHA-256 | 64 | 128 bits |
| SHA-384 | 96 | 192 bits |
| SHA-512 | 128 | 256 bits |
| SHA3-512 | 128 | 256 bits |
128 bits of collision resistance already means roughly 340 undecillion attempts — a number with 39 digits, unreachable with every computer that exists or is planned. Doubling something unreachable does not make your download safer. What the extra bits protect against is not an attacker but the future: a structural weakness discovered in SHA-2 would eat into that margin, and starting from 256 bits leaves more room than starting from 128.
Two other comparisons people expect to be simple and are not. Speed is one: SHA-512 moves through more bytes per round of work because it operates on 64-bit words, so on 64-bit hardware it can be the quicker of the two per byte hashed, which surprises everybody who assumes the bigger number costs more. On a Mac, both are faster than almost any disk can supply data, so the difference rarely shows up in a wall clock — SHA-256 versus SHA-512 has the real comparison.
Length extension is the other. Both SHA-256 and SHA-512 leak their internal state in their output, so given a digest and the length of the input, somebody can compute the digest of that input with extra bytes appended, without knowing the original. For file checksums this does not matter at all. For anything where you are hashing a secret together with a message, it does — and choosing SHA-512 over SHA-256 does not help, because both have the weakness. SHA-384, being truncated, and the SHA-3 family, being built differently, do not.
Where SHA-512 is genuinely the right answer
Four situations, and in the first three you have no choice to make.
- Something specified it. A procurement requirement, a government profile, a protocol definition, an API that signs with it. Arguing with the document is not your job; match it exactly.
- The checksum you are checking against is a SHA-512. Debian’s image directories, for instance, carry a
SHA512SUMSfile alongside the shorter one. You cannot compare across algorithms, so produce whichever one the publisher published. - It is hiding inside key derivation. HMAC-SHA-512 is the core of BIP-32 hierarchical wallet derivation, and PBKDF2 built on HMAC-SHA-512 turns up across disk and credential encryption. You will not be computing these by hand, but it is why the name appears in places that have nothing to do with downloads.
- You want 512 bits of internal state and a short output. That is what the truncated variants are for — SHA-512/224 and SHA-512/256, the SHA-512 engine with its own initial values and its output cut down. They are rare, they are not among the app’s eight algorithms, and their digests match neither a SHA-512 nor a SHA-256 of the same input, so when a specification names one it means that function and not a near relative of it.
The strings beginning $6$ in a Unix password file are sha512-crypt: a salt plus thousands of repeated rounds, written in base64, 86 characters long. A plain SHA-512 of the password will never match one, and should never be used in its place — why fast hashes are wrong for passwords explains the reasoning.
Comparing 128 characters without reading them
Producing the digest is rarely the end of the errand. Somebody published a value, and what you actually need to know is whether yours equals it — a question 128 characters long, which is well past the point where looking settles anything.
Verify is the third item in the sidebar and it exists to answer exactly that. Its segmented control has two modes, and Against a Checksum is the one for a published value: drop the file into the well, paste the 128 characters, and the algorithm is taken from the value rather than from a menu, so there is nothing to choose first. The verdict appears below as a green seal and a sentence. File vs. File is the other mode, two drop wells side by side with a swap control between them, for the case where nobody published anything and you are comparing a copy against its original.
Most SHA-512 values reach you inside a file rather than on a web page. A SHA512SUMS list is two columns — the digest, two spaces, then the filename — one line per file, and the only line that concerns you is the one whose filename matches your download. This is what that looks like:
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e empty.txt
ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f abc.txtThose two digests are the test vectors from earlier in this page, now in the shape a publisher ships them: an empty file, and a file holding the three letters abc and nothing else, not even a newline. Recognizing the format is the whole skill, because the value you paste into Verify is the first column of one line and never the whole file. What a SHASUMS file is covers the variants you will meet: the asterisk some producers put in front of the filename, and the tagged form that writes the algorithm name and the filename before the digest.
Troubleshooting
I cannot tell where two 128-character values differ
Do not try. Comparing long hex by eye is the one part of this job humans are measurably bad at, and the middle is where attention fails. Hand the file and the published value to Verify instead and read the seal: a verdict is yes or no, where a visual comparison only ever reaches “I did not spot a difference”. If you have no way to do that, compare the first eight characters and the last eight — that catches accidental corruption, which has no way to preserve them, though it is no defense against anything deliberate.
The published value is 128 characters but my digest does not match
Check that it is the same 128-character algorithm. SHA-512 and SHA3-512 have identical output lengths and completely different internals, so a length match proves nothing — identifying which algorithm a checksum uses covers the ambiguous lengths, and generating a SHA-3 digest is the other half of the answer if it turns out to be Keccak.
The form rejected my digest as too long
It wanted 64 characters, which means SHA-256, not SHA-512. Fields validating a checksum’s length are common and they are rarely labeled clearly. Count the characters the field will accept and produce the matching algorithm rather than trimming your digest to fit — half a SHA-512 is not a SHA-256 and will not match anything.
SHA-512 is slower on my Mac, not faster
Most likely you are timing the disk rather than the algorithm, or hashing thousands of small files where the per-file overhead swamps the arithmetic entirely. Hash one large file that is already in the system cache and time that instead; the numbers only mean something when the storage is not the bottleneck.
My SHA-512 does not match what the other system stored
If the stored value starts with $6$, it is not a digest at all but a salted, iterated password hash, and no amount of plain SHA-512 will reproduce it. If it is 128 characters but still wrong, check what was hashed rather than how: a string with a trailing newline, a file with Windows line endings, or a JSON document serialized differently at each end will all hash correctly to different answers.
Frequently asked questions
How many characters is a SHA-512 hash?
128 hexadecimal characters — 512 bits, or 64 bytes — whatever you hand it, from an empty file to a 50 GB disk image. Two cautions come with that number. SHA3-512 is also 128 characters, so the length does not tell you which family a digest came from; and the first 64 characters of a SHA-512 are not a SHA-256, so a value trimmed to fit a shorter field will never match anything.
Is SHA-512 more secure than SHA-256?
On paper yes — 256 bits of collision resistance against 128 — but both numbers are far beyond what any attacker can search, so for checking files the practical difference is zero. The real reason to choose SHA-512 is that something requires it, or that you want more margin in case a future weakness eats into it. For a download checksum, SHA-256 is the better choice simply because everyone can verify it.
Is SHA-512 faster or slower than SHA-256?
Often faster per byte on 64-bit hardware, which catches people out. SHA-512 processes 1024-bit blocks using 64-bit words, so it covers more input per round of work than SHA-256 does with its 32-bit words. In practice the disk supplies data more slowly than either algorithm consumes it, so on a whole file you are unlikely to measure a difference.
How do I generate a SHA-512 hash on a Mac without Terminal?
Use a hashing app: type the text into the Text tool, or drag the file into the Files tool, and read the SHA-512 row — third under the SHA-2 heading, after SHA-256 and SHA-384. There is nothing to configure, and although the row shortens the value in the middle to fit, clicking it copies all 128 characters. Nothing is uploaded. When the input is a string rather than a file — an API key, a line from a config, a value somebody sent you — the SHA-512 generator on this site runs the same arithmetic on text in a browser tab; a file on disk is the Files tool's job.
What is the difference between SHA-512 and SHA3-512?
Only the output length is the same. SHA-512 belongs to SHA-2 and compresses the input block by block into a chained state; SHA3-512 is Keccak, which absorbs the input into a large internal permutation instead. They produce entirely different 128-character digests for the same input, and neither can be checked against the other. SHA-3 exists as insurance, not as a replacement.
Why does my Linux password hash start with $6$ instead of being 128 characters?
Because it is not a SHA-512 digest. The $6$ prefix marks sha512-crypt, which combines a salt with thousands of repeated SHA-512 rounds and writes the result in a base64 alphabet, 86 characters long. It is deliberately slow, where a plain digest is deliberately fast, and a plain SHA-512 of the same password will never match it.
Can a SHA-512 hash be reversed or cracked?
No. There is no method of recovering a 512-bit digest's input that beats guessing inputs one at a time, and the digest keeps only 64 bytes of a file that may have been gigabytes. Short, predictable inputs are a different matter — not because SHA-512 is weak, but because there are few enough candidates to try them all, which is why passwords need a slow salted function rather than any plain hash.