SHA-512 is a 512-bit cryptographic hash function standardized in NIST FIPS 180-4, and a correctly generated SHA-512 digest is always exactly 64 bytes, rendered as 128 lowercase hexadecimal characters or as standard padded Base64. To generate a SHA-512 hash, you provide the exact UTF-8 text or raw file bytes, run the algorithm, and copy the representation the consumer expects (Hex or Base64 of the same 64 bytes). The output length is fixed by the specification, not by the input length: an empty string and a multi-gigabyte file both produce a 128-character hex string. Adding a single period, swapping LF for CRLF, normalizing Unicode, or including a byte-order mark changes every character of the digest, because SHA-512 is deterministic and highly sensitive to every byte. The browser can perform this calculation locally, so neither your message nor your file leaves your device. A SHA-512 result that does not match the standard 128-character length almost always signals a truncated variant somewhere in the chain. SHA-512/256, SHA-512/224, SHA-384, and HMAC-SHA-512 all share parts of the SHA-512 compression function but produce different outputs and are not interchangeable. Comparing every character against a NIST, OpenSSL, or RFC 6234 reference value is the only reliable way to confirm the result is genuine full SHA-512.
How SHA-512 Works and Why the Output Length Is Fixed
SHA-512 is part of the SHA-2 family and operates on 64-bit words. The algorithm pads the input into 1024-bit blocks, expands each block into an 80-word message schedule, and updates eight 64-bit state values across 80 rounds. The final concatenation of those eight state values is the 512-bit output. Because the state size is fixed, the output is always 64 bytes regardless of how short or long the input is. There is no truncation step and no length extension inside the algorithm itself; what you see is the full digest.
Those 64 bytes can be displayed in two equivalent ways:
- Lowercase Hex - 128 characters, two hex digits per byte. This is the most common format for checksums, software release notes, and protocol specs.
- Padded Base64 - standard RFC 4648 Base64 of the same 64 bytes, roughly 88 characters including padding. Same bits, more compact.
Both representations describe the same digest. Choosing between them is purely about what the consumer expects to paste, log, or transmit.
How to Generate a SHA-512 Hash in Your Browser
The fastest way to produce a verified SHA-512 digest for text or a local file is the Sha512 Hash Generator. The whole workflow runs locally, so nothing is uploaded.
- Open the Sha512 Hash Generator and pick the input mode: Text for a UTF-8 string or File for raw bytes. Whitespace and line endings are part of the input, so include them exactly as the consumer expects.
- Provide the source. Paste text into the text area, or select a local file. File mode reads bytes directly, with no character-set decoding, no MIME sniffing, and no filename-based transformation. A binary file hashed as a file is hashed as bytes.
- Generate the digest. The tool computes the full FIPS 180-4 SHA-512 over your exact bytes and reports the byte count for text mode.
- Copy the representation the consumer requires - 128-character lowercase Hex or padded Base64. Both represent the same 64 digest bytes.
- Compare every character against a trusted reference. The expected value must arrive through an authenticated path: a NIST publication, the software publisher's signed release notes, an OpenSSL command run locally, or the protocol specification itself. Never copy the expected value from the same artifact you are checking.
Eight built-in fixtures - the empty sequence, "abc", the FIPS multi-block message, punctuation variants, UTF-8, arbitrary binary bytes, and common prose - are checked against NIST and RFC sources and independently reproduced with OpenSSL. A separate assertion confirms the exact Base64 encoding of the standard "abc" digest, so the tool's two output formats cannot drift apart.
SHA-512 and Its Variants - What Is and Isn't Full
Several algorithms share parts of SHA-512's compression routine but produce different digests. If the protocol specifies one of these variants, full SHA-512 is the wrong tool and the output will not match.
| Algorithm | Output bits | Hex length | Source |
|---|---|---|---|
| SHA-256 | 256 | 64 | FIPS 180-4 |
| SHA-384 | 384 | 96 | FIPS 180-4 |
| SHA-512 (full) | 512 | 128 | FIPS 180-4 |
| SHA-512/224 | 224 | 56 | FIPS 180-4 |
| SHA-512/256 | 256 | 64 | FIPS 180-4 |
| HMAC-SHA-512 | 512 | 128 | RFC 2104 / RFC 4231 |
SHA-512/256 and SHA-512/224 use different initial hash values, not just a smaller output window. Manually truncating a full SHA-512 to 64 hex characters will not equal a real SHA-512/256 result. SHA-384 also uses different initial values and a truncated round count. HMAC-SHA-512 requires a key and produces a keyed authentication tag; its output is not interchangeable with raw SHA-512 even at the same length.
When verifying against a published checksum, always check which algorithm the publisher actually specifies. A 128-character hex value labeled "SHA-512" is full SHA-512; a 64-character hex value labeled the same way is almost certainly SHA-512/256 in disguise.
Where a 512-Bit Digest Fits in Real Workflows
Choosing SHA-512 over a shorter SHA-2 member is rarely about security strength in isolation, because SHA-256 and SHA-512 share an identical collision-resistance claim within the SHA-2 family. The choice usually comes from one of three workflow constraints.
- The protocol mandates 512 bits. Some TLS cipher suites, certificate transparency logs, and signature schemes reference SHA-512 by name. Producing a SHA-256 digest there would not satisfy the spec no matter how strong it is in other contexts.
- Software integrity against a published checksum. Several Linux distributions and open-source projects publish SHA-512 sums alongside downloads. The reference and the artifact must use the same algorithm, and the consumer is responsible for fetching the reference over an authenticated channel.
- Long identifier comparison. Embedding SHA-512 in chained log records, content-addressable storage, or reproducible-build pipelines gives a strong per-record fingerprint that is robust against accidental collisions.
For a deeper look at output-format selection and the Hex/Base64 trade-off in the same workflow, see Create a SHA-512 Hash and Choose the Output Format You Need.
What SHA-512 Does Not Do
SHA-512 is one-directional. There is no decryption key, no inverse operation, and no shortcut back to the original input other than brute-force search over the input space. It also does not authenticate origin. Two consequences matter when choosing it:
- Authentication needs a key or a signature. HMAC-SHA-512 binds a shared secret to the digest for symmetric authentication. A public-key signature - RSA, ECDSA, or Ed25519 - provides asymmetric origin verification. A bare SHA-512 value proves nothing about who computed it.
- Password storage needs a slow, salted function. General-purpose hashes are intentionally fast, which makes offline guessing cheap. Modern password databases use memory-hard functions with per-account salts: Argon2id, scrypt, or bcrypt with appropriate work parameters. The browser tool adds no salt, no stretching, no account context, and no secret pepper; it computes exactly what FIPS 180-4 specifies.
Choosing a longer raw digest does not repair these gaps. Pick the construction the protocol requires: HMAC-SHA-512 if both parties share a secret, a signature if the verifier must trust an asymmetric public key, and a dedicated password function if the goal is verifier-side credential storage.
Practical Limits of an In-Browser Implementation
The browser-based calculation accepts up to 100 MB of UTF-8 text or raw file bytes in a single buffer. The 100 MB ceiling is a tab-responsiveness decision, not a SHA-512 limitation; the underlying algorithm supports messages far larger in theory. For multi-gigabyte disk images, archives, or video files, run a streaming implementation locally and compare the full output after the operation completes.
Several implementation details protect the result from common mistakes:
- Text mode converts the input to UTF-8 before hashing and reports the resulting byte count, so you can confirm the encoding step actually saw what you intended.
- File mode hashes raw bytes without interpreting the filename, character set, or MIME type. This prevents the common error of decoding a binary file as text and then hashing a modified representation rather than the original artifact.
- Asynchronous job identity is monotonically increasing, so changing input mode (text to file or vice versa) mid-operation cannot let a stale result overwrite the new state.
- Copy controls expose only the digest representation. Selected file bytes never reach the clipboard, even if you copy repeatedly.
Empty text is a valid message, not an absent calculation. The standard SHA-512 of an empty UTF-8 string begins with cf83e135 and runs the full 128 characters. Generate explicitly rather than letting a blank field skip the calculation.
If you're weighing options, Base32 Decode: How Five-Bit Groups Rebuild UTF-8 Text covers this in detail.