SHA-512 hash generator

The value above is 128 characters long, which is the first thing anybody notices about SHA-512 and the least interesting thing about it. What separates it from SHA-256 is not the size of the output but the width of the arithmetic inside, and that is where both its speed and its reputation come from.

Where the other 64 characters come from

SHA-256 works on 32-bit words, chews through the input in 512-bit blocks, and runs 64 rounds on each one. SHA-512 is the same shape of machine rebuilt in 64-bit words: 1024-bit blocks, 80 rounds, round constants taken from the cube roots of the first 80 primes instead of the first 64, and a 128-bit counter for the message length instead of a 64-bit one. Eight 64-bit words of state come out at the end, which is 512 bits, 64 bytes, or the 128 hexadecimal characters you are looking at.

That redesign has a consequence people find backwards. In plain software on a 64-bit processor, SHA-512 usually moves through a file faster per byte than SHA-256 does, because it handles 128 bytes per block instead of 64 and the extra rounds do not cost enough to make up the difference. On 32-bit hardware the same property makes it the slow one, since every 64-bit operation has to be faked. And on a machine whose silicon implements SHA-256 directly, the ordering can flip back again — which is why the honest answer to “which is faster” is to measure it on the Mac in front of you rather than reason about it. SHA-256 versus SHA-512 goes through the comparison properly.

Is SHA-512 twice as strong as SHA-256?

It depends entirely on which property you mean, and the two get run together constantly. Preimage resistance is the difficulty of working backwards from a digest to an input that produces it: for SHA-256 that is on the order of 2²⁵⁶ attempts, for SHA-512 it is 2⁵¹². Collision resistance is the difficulty of finding any two inputs at all that share a digest, and it is only half the digest length because of the birthday bound — 128 bits for SHA-256, 256 bits for SHA-512.

Collision resistance is the number that matters when a digest is standing in for a file, because an attacker who wants to swap one file for another does not need to hit a specific digest; they need two files that agree. It is also the property MD5 lost in 2004 and SHA-1 lost publicly in 2017, when two different PDFs with the same SHA-1 were published. Both of those algorithms are still perfectly hard to reverse; that is not the part that failed.

So the upgrade is real in the arithmetic and invisible in practice. 2¹²⁸ attempts is already beyond every computer that exists or is planned, and doubling an unreachable number does not make your download more verified than it was. What the extra margin actually buys is room to survive a future structural discovery: if somebody finds a weakness that cuts the effort by forty bits, starting from 256 leaves you comfortable and starting from 128 leaves you reading security advisories.

Where SHA-512 is the thing being asked for

Usually you are not choosing it. Something in front of you has specified it, and these are the places that do:

• Ed25519 signatures. The scheme hashes with SHA-512 internally at several points, as part of signing and verifying rather than as something you configure. If you have an SSH key of that type, you are using SHA-512 whether you think about it or not.
• Linux password entries beginning $6$. That marker means sha512crypt, which is SHA-512 wrapped in thousands of iterations of salting and re-hashing. A bare SHA-512 of the password will never match it, and that is the point.
• HMAC-SHA-512 and HS512 tokens. Signed JWTs and webhook signatures often specify it, and there the digest is keyed rather than public.
• Projects that publish a SHA512SUMS file. Debian's installation images ship one next to the SHA-256 list. Use whichever the publisher signed, not whichever you prefer.
• Long-horizon archives. When a manifest has to stay meaningful for decades — preservation stores, legal holds, scientific data — the extra collision margin is cheap insurance against being the person who picked the short one.
• Filesystem checksums. OpenZFS can checksum every block with the SHA-512 engine, for people who want cryptographic strength from the layer that is already reading every byte. Note what its sha512 setting actually stores: the SHA-512/256 truncation, because the checksum field in a block pointer is 256 bits wide.

Conspicuously absent: verifying a download from a publisher who gave you a SHA-256. Matching the published algorithm is the entire job, and picking a longer one unilaterally just means you have nothing to compare with. When nothing has named one for you, which algorithm to use settles it in a paragraph.

What this tab hashes

Text, and only text. What you type is encoded as UTF-8 and hashed in the tab on every keystroke, with no request made and nothing stored — open your browser's network inspector and watch it stay empty, or turn off Wi-Fi and reload and notice that the page still works. That makes it a reasonable place for a value you would rather not hand to a server: a key you are checking, a line out of a config file, a string somebody sent you with a digest attached.

It is not a place to hash a file, because it has no way to read one, and at this width that distinction bites harder than it does at 64 characters. A 128-character digest is nearly always travelling with a file — a SHA512SUMS line beside a Debian image, a row in an archive manifest, a preservation record — and a file's digest covers every byte on disk, including the trailing newline a one-line text file almost always carries. Paste that file's contents into the box and you get the digest of the text you pasted, which is a different value answering a different question. Why two tools give different hashes goes through the rest of the ways the two drift apart.

The truncations that are not SHA-512

Two standardized algorithms are built out of the SHA-512 machine and stopped early, and either of them will hand you a digest that looks like it belongs to something else. SHA-512/256 runs the same 64-bit arithmetic and publishes only 256 bits of the final state, so what comes out is 64 characters — and it is neither the SHA-256 of your file nor the first 64 characters of its SHA-512. SHA-384 is the same idea cut at 384 bits. Both begin from their own initial values rather than SHA-512's, which is exactly why a digest cannot be shortened by hand: trim a SHA-512 yourself and you have a string that matches nothing anybody else will ever compute.

So a 64-character value from something that said SHA-512 is not a corruption and not a bug, it is a different member of the family, and the only way through is to find out which one was specified. Identifying an algorithm from its digest has the table of lengths and the cases where length alone runs out.

Doing this without a tab open

Close the tab and everything here is gone, which is fine once a month and tiresome every week. Rocket Hash is the same arithmetic in a native Mac app, and its Text tool is the box above without the tab: every digest at once as you type, SHA-512 sitting under the SHA-2 heading beside SHA-256 and SHA-384, a byte count on the left and Copy All on the right. That part is free.

The parts a tab cannot reach at all belong to the Files tool: a file, a whole folder hashed in one run, each file read exactly once however many digests you want from it, roughly 2 GB/s for SHA-256 on Apple Silicon — where the disk rather than the algorithm is usually what you are waiting for — a job you can pause mid-file and resume from the exact byte, and a shasum-compatible manifest exported at the end. At this width the Verify tool is the one that pays for itself — paste the published 128 characters into Against a Checksum, drop the file beside them, and the answer is a green seal and a sentence rather than two very long strings your eyes are about to skim. The algorithm is detected from the checksum you paste, so nothing has to be chosen first, and File vs. File answers the other version of the question with two drop wells and a swap control between them.

Clicking a digest row copies that value whole, which on a 128-character string matters more than it sounds: the row shortens the middle with an ellipsis to fit, and an ellipsis pasted into a ticket is how a verification fails for no reason anybody can find. Generating a SHA-512 on a Mac walks through the whole route, and verifying a download covers where a published value should have come from before you trust it.

Frequently asked questions

Is SHA-512 just SHA-256 run twice?

No. They are separate algorithms with separate specifications. SHA-512 operates on 64-bit words instead of 32-bit ones, processes 1024-bit blocks instead of 512-bit blocks, runs 80 rounds instead of 64, and starts from different initial values. Running SHA-256 twice gives you a 64-character value that has nothing to do with SHA-512 — that construction is what Bitcoin uses, and it is not a wider hash.

Why does my SHA-512 hash have a line break in the middle of it?

Because something wrapped it, not because the digest has a structure. A SHA-512 digest is one unbroken run of 128 hexadecimal characters, and mail clients, terminals and text editors routinely fold lines at 64, 76 or 80 columns. Join it back into a single line before comparing, and check that no space survived in the middle — a wrapped digest fails every comparison in a way that looks exactly like a corrupted file.

Can I store a SHA-512 hash in a 64-character column?

Not as hexadecimal. You need 128 characters, or 64 bytes if you store the raw digest in a binary column. A 64-character column silently truncates it in some databases, after which every comparison fails and nothing explains why — a column sized for SHA-256 is the single most common cause of a SHA-512 that never matches itself.

Can two different files have the same SHA-512 hash?

In principle, yes: there are infinitely many possible inputs and only 2⁵¹² possible digests, so collisions must exist. In practice no pair has ever been found, for SHA-512 or for any member of SHA-2, and the expected effort to find one is around 2²⁵⁶ attempts. Treating a matching SHA-512 as proof the bytes are identical is sound.

Why do most download pages publish SHA-256 rather than SHA-512?

Convention and tooling, mostly. SHA-256 became the default before SHA-512 had much tool support, 64 characters are easier to put on a web page than 128, and the security difference is invisible at the scale anybody cares about. Several projects publish both. When you are checking a download, use the algorithm the publisher used — producing a SHA-512 for a file whose published value is SHA-256 leaves you with nothing to compare against.

What is SHA-512/256, and is it the first half of a SHA-512?

It is a distinct algorithm from FIPS 180-4: SHA-512 run from its own initial values and cut to 256 bits, so you get a 64-character digest out of 64-bit arithmetic. It is not the first 64 characters of the SHA-512 digest of the same input, and it is not SHA-256 either. If something hands you 64 characters while calling them SHA-512, this is usually what you are looking at.