The big sibling of SHA-256: when its 128-character digest and 64-bit arithmetic actually buy you something, what SHA-384 quietly fixes, and the length extension property that catches people who roll their own authentication.
SHA-512 in one paragraph
SHA-512 is the other half of the SHA-2 family from FIPS 180-4: same construction as SHA-256, scaled up. It works on 64-bit words instead of 32-bit, processes 128-byte blocks instead of 64, runs 80 rounds instead of 64, and emits a 512-bit digest, 128 hex characters. Nothing about it is "more modern" than SHA-256; both were published together in 2001, and both are unbroken. The differences that matter are practical: digest length, speed characteristics, and which truncated variants each engine can feed.
SHA-512 vs SHA-256
| SHA-256 | SHA-512 | |
|---|---|---|
| Digest | 256 bit / 64 hex | 512 bit / 128 hex |
| Block size | 64 bytes | 128 bytes |
| Word size | 32 bit | 64 bit |
| Software speed on x86-64 | baseline | ~1.5x faster on long inputs |
| With SHA-NI hardware | much faster | no hardware support |
| Length extension | affected | affected (SHA-384: no) |
The speed rows explain most real-world decisions. In pure software on a 64-bit machine, SHA-512 moves more data per round and wins on long inputs. But recent x86 and ARM cores ship SHA-256 instructions (SHA-NI, ARMv8 crypto extensions) and no SHA-512 equivalent until very recent ARM revisions, which flips the ranking on exactly the hardware most servers run. Benchmark on your target before choosing for throughput, and default to SHA-256 when in doubt, because everything interoperates with it.
How to use this generator
- Hash text or files: type, paste or drop; the digest updates live from the Web Crypto API. Dropped files are hashed byte for byte, and the download becomes a checksum file that
sha512sum -caccepts. - Switch variants:
--sha384computes SHA-384 from the same input; the DIGEST stat drops to 384 and the verify logic follows along. - Verify: paste an expected value and the comparison names the first differing character, or tells you the paste has the length of a SHA-256 or MD5 when the algorithm is the actual mismatch.
Length extension, explained with a shipping example
Suppose an API authenticates requests with sha512(secret + params), a design that looks reasonable and appears in real codebases. The digest of a Merkle–Damgård hash is its internal state after the last block, so anyone holding a valid hash can resume the computation: append the padding the hash would have added, then their own &admin=true, and produce a valid hash for the extended message, all without knowing the secret. Flickr's API was broken exactly this way in 2009.
Three constructions close the hole: HMAC (the standard answer, built for this in 1996 and available on our HMAC generator), hashing with a truncated variant like SHA-384 whose published digest hides part of the state, or the modern hashes (SHA-3, BLAKE2/3) that are structurally immune. What does not close it is secrecy of the message format or key length; the attack needs neither.
The truncated variants
The SHA-512 engine feeds a small family. SHA-384 changes the initial values and cuts the output to 48 bytes; TLS certificate chains on P-384 curves and the SHA384 cipher suites use it, and it is the variant this page computes behind the --sha384 flag. SHA-512/256 and SHA-512/224 do the same trick at other lengths, giving 64-bit hashing speed with SHA-256-sized digests and length-extension immunity; support outside OpenSSL and newer language runtimes is spotty, which is the main reason they stayed niche.
The practical summary: SHA-512 for long-input throughput in software, SHA-384 where TLS or length-extension resistance points at it, SHA-256 everywhere else. All three share the security story, unbroken with enormous margin, so none of these choices is a security trade-off.
SHA-512 questions
Should I use SHA-512 or SHA-256?
For most jobs, SHA-256: it is the ecosystem default, its 64-character digest is half the storage, and its security margin is already unreachable. SHA-512 wins in two situations. On 64-bit CPUs without SHA hardware extensions it is often 1.5x faster for large inputs, because it processes 128-byte blocks with 64-bit arithmetic. And if you need to hash-then-truncate for length-extension resistance, SHA-512/256 and SHA-384 come from this engine. Security-wise both are unbroken; the choice is about compatibility and throughput, not strength.
What is SHA-384 and when would I use it?
SHA-384 is SHA-512 with different initial constants and the output cut to 384 bits (96 hex characters). You meet it mostly in TLS: ECDSA-P384 certificate chains and the TLS_AES_256_GCM_SHA384 cipher suite pair with it, and Subresource Integrity examples often use sha384-… hashes. Its quiet advantage is that truncation hides the internal state, so SHA-384 is immune to length extension attacks that affect plain SHA-256 and SHA-512. If you are designing something new and want SHA-2 without that footgun, SHA-384 is a sensible default.
What is a length extension attack and which hash functions are affected?
For Merkle–Damgård hashes (MD5, SHA-1, SHA-256, SHA-512), the digest of a message equals the internal state after processing it. An attacker who knows hash(secret + message) and the length of the secret can therefore resume hashing and compute a valid hash(secret + message + padding + extra) without knowing the secret. That breaks naive authentication schemes of the form sha256(key + data). Truncated variants (SHA-384, SHA-512/256), SHA-3 and BLAKE2/3 are immune because the published digest is not the full internal state. The standard fix is not switching hashes but using HMAC, which was designed against exactly this.
Is SHA-512 good for password hashing, like sha512crypt in /etc/shadow?
sha512crypt (the $6$ entries in Linux shadow files) is not one SHA-512 call but thousands of iterated rounds with a salt, 5,000 by default, which made it acceptable in 2008. Today it is the weakest of the still-common choices: the rounds are CPU-cheap for GPUs, and there is no memory cost. A single plain SHA-512, even salted, is not password hashing at all. Current distributions have moved to yescrypt for exactly this reason, and for application code the answer is bcrypt or Argon2, not any bare SHA variant.
How long is a SHA-512 hash in hex and Base64?
512 bits are 64 bytes: 128 characters in hex, 88 in Base64 (86 plus == padding, or 86 in unpadded Base64URL). SHA-384 is 48 bytes: 96 hex or 64 Base64 characters. A practical consequence is column sizing: a CHAR(128) fits any hex SHA-512, and if a value claiming to be SHA-512 has a different length, it is either a different algorithm or truncated in transit, which is exactly what the verify field on this page checks before comparing.
What is SHA-3, and does it replace SHA-2?
SHA-3 (Keccak, standardised 2015) is a different construction, a sponge instead of Merkle–Damgård, selected by NIST as a hedge in case SHA-2 ever cracks. It did not replace SHA-2 and was never meant to: SHA-2 remains unbroken, faster in most software, and universally deployed. SHA-3 adoption is thin outside Ethereum (which uses a pre-standard Keccak variant) and some protocol niches. Practical guidance in 2026: use SHA-256 or SHA-512 for compatibility, BLAKE3 for raw speed, and reach for SHA-3 only when a spec demands it.