SHA-512 is usually the faster one, which surprises people
The intuition says a 512-bit hash costs twice as much as a 256-bit hash. On a 64-bit processor without hardware hash instructions, the opposite holds. SHA-512 works on 64-bit words and swallows 1024 bits per block, against 32-bit words and 512-bit blocks for SHA-256. It runs 80 rounds instead of 64, but each round moves twice the data, so the throughput per byte lands around 30 to 50 percent better.
Then Intel shipped SHA-NI in 2016, accelerating SHA-1 and SHA-256 in silicon while leaving SHA-512 to plain software. On most x86 desktops and servers sold since, the ranking flips and SHA-256 wins by a wide margin. Recent Intel and ARMv8.2 parts add SHA-512 instructions, so the answer depends on the exact chip in front of you. If you benchmark one machine and generalise, you will be wrong on the next one.
None of this decides your algorithm choice. Both are unbroken, both are FIPS approved, and disk speed dominates file hashing long before the hash does. Pick SHA-512 when a protocol asks for it, when you want the wider output for key derivation, or when the checksum file you are checking against was made with it.
The SHA-2 family, side by side
All six variants share one compression function design. The differences are word size, output length, initial values, and whether the output is truncated.
| Variant | Word size | Block | Rounds | Digest | Hex chars | Resists length extension |
|---|---|---|---|---|---|---|
| SHA-224 | 32 bit | 512 bit | 64 | 224 bit | 56 | Yes |
| SHA-256 | 32 bit | 512 bit | 64 | 256 bit | 64 | No |
| SHA-384 | 64 bit | 1024 bit | 80 | 384 bit | 96 | Yes |
| SHA-512 | 64 bit | 1024 bit | 80 | 512 bit | 128 | No |
| SHA-512/224 | 64 bit | 1024 bit | 80 | 224 bit | 56 | Yes |
| SHA-512/256 | 64 bit | 1024 bit | 80 | 256 bit | 64 | Yes |
The truncated variants are not SHA-512 with the end cut off. Each starts from its own set of initial values, derived by running SHA-512 over the variant name with every initial word flipped by 0xa5a5a5a5a5a5a5a5. Chop 256 bits off a SHA-512 digest yourself and you get a different number from what SHA-512/256 produces. People building interoperable code discover this the expensive way.
Length extension, the property nobody mentions until it bites
SHA-512 follows the Merkle-Damgård construction. The digest is the internal state after the final block, published in full. Anyone holding a digest holds the machine state, and they resume from there.
Say a service authenticates requests by sending sha512(secret || message). An attacker who never learns the secret still forges a valid tag:
// what the server computestag = sha512(secret + "user=bob&role=guest")// what an attacker sends, knowing only the tag and the messageforged_message = "user=bob&role=guest" + padding + "&role=admin"
forged_tag = sha512_resume(tag, "&role=admin")// the server recomputes and agrees, without the secret ever leakingThe padding block is deterministic, so the attacker constructs it from the known message length alone. Three fixes work, in order of preference: use HMAC-SHA-512, switch to a truncated variant like SHA-512/256, or move to SHA-3, whose sponge design never exposes the full state. Never patch it by reordering to sha512(message || secret), which trades one weakness for another.
The plain digest field above is the naked construction. For anything an attacker benefits from forging, wrap it in HMAC.
Checking a download against SHA512SUMS
This is the job SHA-512 does most often. Debian, Arch, Tails, Fedora and most language runtimes publish a checksum file next to the release, and the comparison catches a corrupted transfer or a swapped mirror before you run the installer.
- Download the release file and the checksum file from the project site, not from the mirror serving the download.
- Open the checksum file and find the line for your exact filename. A release with 40 architecture builds has 40 lines, and picking the wrong one produces a mismatch nothing is wrong with.
- Drop your download into the File tab above and wait for the digest.
- Paste the whole line, filename column included, into the compare box. The filename and spacing are stripped before the check.
- On a match, verify the checksum file signature with GPG. Without that step you proved the file arrived intact, not the correct file to begin with.
The same check from a terminal:
# Linuxsha512sum ubuntu.iso
sha512sum -c SHA512SUMS 2>&1 | grep OK# macOSshasum -a 512 ubuntu.iso# Windows PowerShellGet-FileHash ubuntu.iso -Algorithm SHA512# Windows cmd, output arrives spaced and uppercasecertutil -hashfile ubuntu.iso SHA512Hexadecimal case carries no meaning. CF83E1 and cf83e1 are the same number, and the compare box treats them as equal. PowerShell returns uppercase, sha512sum returns lowercase, and certutil inserts a space every two characters, which is why a visual comparison of two correct digests so often looks wrong.
Where SHA-512 actually turns up
Inside signature schemes
Ed25519 hashes with SHA-512 at two points in every signature, over the private key during expansion and over the message during signing. Anyone using modern SSH keys or Signal runs SHA-512 constantly without naming it.
Key derivation
A BIP-39 mnemonic becomes a wallet seed through PBKDF2 with HMAC-SHA-512 across 2048 iterations. HKDF-SHA-512 does the same job in TLS deployments and in application key hierarchies, where the 512-bit output splits into several independent keys.
File integrity at rest
Backup catalogues, archive manifests and package databases store SHA-512 digests because the wider output leaves room for decades of storage without collision worries. ZFS offers it as a checksum algorithm for the same reason.
Not in Bitcoin
Bitcoin mining is double SHA-256. The SHA-256 generator is the page for that, and the confusion comes from SHA-512 sharing a family name rather than a role.
What this page will not do
No reverse lookup. A digest discards the input, and no database sits behind the field. Sites claiming to decrypt SHA-512 are searching precomputed lists of common passwords, which works on letmein and on nothing you would want protected.
No streaming for very large files. Web Crypto needs the whole file in memory before it hashes, so the tool refuses anything over 1.5 GB and a phone browser will run out of room well before then. Reach for sha512sum on a multi-gigabyte image.
No HMAC, no salt, no iteration count. Keyed digests belong in the HMAC Generator, and one input across several algorithms at once belongs in the Hash Generator Suite.
No batch mode. The compare box handles one digest against one input. Checking a folder of files against a full manifest is what Checksum Validator is for.
One more limit worth stating plainly. A matching digest proves the bytes match a value someone published. Whether the publisher was legitimate is a signature question, and no hash tool answers it.
