SHA-512 Hash Generator & Verifier
Generate SHA-512 hashes from text or files and verify them against an expected checksum. Streams large files in your browser, supports UTF-8/UTF-16/Latin-1/Windows-1252 and hex/base64 input, HMAC-SHA512, and hex or base64 output.
Runs entirely in your browser. Text is hashed with the native Web Crypto API and files are streamed through WebAssembly — nothing is uploaded, nothing is logged. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear.
SHA-512 digest
0 bytes hashed — canonical empty-input digestFix the input above to see a digest.
Input
0 characters · 0 encoded bytes
UTF-8 is what sha512sum and every modern web API use. Leave it selected unless you are reproducing a legacy system's hash.
Compare against an expected hash
Paste the publisher's checksum — bare hex, base64, a sha512sum line (hash filename) or a BSD SHA512 (file) = hash tag all work.
The verdict appears as soon as both a digest and an expected hash exist. Works for text and files — the browser equivalent of sha512sum -c.
Other algorithms
Compute MD5, SHA-1, SHA-256 and SHA-512 of the same input to identify an unknown digest. Loads a small WebAssembly module (for MD5) on demand — that is why it is opt-in.
A longer digest is not a password hash
SHA-512 is secure but fast — and on 64-bit CPUs it is often faster than SHA-256, which makes it just as wrong for storing passwords. A GPU cluster brute-forces unsalted or salted SHA-512 password hashes at billions of guesses per second. Use a deliberately slow, memory-hard function instead: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2-HMAC-SHA512 at 210,000+ iterations (OWASP). Note that Linux's $6$ shadow entries are not raw SHA-512 either — they are 5,000 rounds of a SHA-512-based KDF.
Why two tools disagree about "the" SHA-512 of your text
- • A trailing newline.
echo "abc" | sha512sumhashes 4 bytes, not 3. Useecho -nor this tool's trailing-newline toggle. - • A BOM. UTF-16 (and sometimes UTF-8) files from Windows editors start with 2–3 extra bytes that most online tools silently add and CLIs never do.
- • The encoding itself. "café" is 5 bytes in UTF-8, 4 in Latin-1, 8 in UTF-16 — three different digests for the same visible text.
- • Byte order. UTF-16LE and UTF-16BE hold the same characters in opposite byte order and therefore hash differently.
- • SHA-512/256 vs truncated SHA-512. SHA-512/256 uses different initial values — it is not the first 32 bytes of a SHA-512 digest, so truncating this output will never reproduce it.
Technical specifications
- • Algorithm: SHA-512, the 512-bit member of the SHA-2 family (NIST FIPS 180-4)
- • Output: 512 bits = 64 bytes = 128 hex characters = 88 base64 characters
- • Block size: 1024-bit blocks, 64-bit internal words, 80 rounds, Merkle–Damgård construction
- • Empty input: SHA-512 of zero bytes is
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e - • Performance: typically 1.2–1.5× faster than SHA-256 on 64-bit CPUs, and slower on 32-bit hardware, because it works on 64-bit words
- • Length extension: like all Merkle–Damgård hashes, SHA-512 is vulnerable — never authenticate with
hash(secret ‖ message), use HMAC - • Text engine: native
crypto.subtle.digest(Web Crypto API) - • File engine: hash-wasm streaming SHA-512, 4 MiB chunks, constant memory use
- • Verification: hex compared case-insensitively, base64 compared case-sensitively (base64 is a case-significant alphabet)
Common use cases
SHA512SUMS) alongside a GPG signature.About SHA-512 Hash Generator & Verifier
The SHA-512 Hash Generator & Verifier computes 512-bit SHA-2 digests of text or files and checks them against a hash you already have. Text is hashed live as you type with the browser's native Web Crypto API; files are streamed through WebAssembly in 4 MiB chunks, so a multi-gigabyte ISO is hashed without ever being loaded into memory. Input can be interpreted as UTF-8, UTF-16LE, UTF-16BE, ISO-8859-1, Windows-1252, raw hex or base64 bytes, and the 128-character digest can be read as lower-case hex, upper-case hex or base64.
Why use a SHA-512 Hash Generator & Verifier?
Most online SHA-512 tools quietly make one of three mistakes: they prepend a byte-order mark to UTF-16 input, they refuse empty input (so you can never see the canonical cf83e135… digest), or they lowercase both sides when verifying — which breaks base64 comparison, because base64 is case-significant. This tool does none of those. It hashes exactly the bytes you asked for, allows empty input, streams real files instead of pretending text is enough, and tells you which format it compared and why the verdict came out the way it did.
Who is it for?
Release engineers verifying a distribution against a SHA512SUMS file, developers debugging HMAC-SHA512 signatures and BIP-32 key derivation, teams choosing between SHA-256 and SHA-512 for a new protocol, and anyone whose terminal and online tool disagree about the digest of the same text and needs to find out which byte differs.
How to use the tool
Choose Hash Text to hash typed input, or Hash File to checksum a file from disk.
In text mode, type or paste your input — the 128-character SHA-512 digest updates live above the input box, and an empty box shows the canonical empty-input digest cf83e135…da3e.
Pick the input encoding: UTF-8 (the default, and what sha512sum uses), UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 bytes.
If you are reproducing a hash from a file that starts with a byte-order mark, tick 'Prepend a BOM'; leave it off to match command-line tools.
Tick 'Append a trailing newline' when reproducing echo "text" | sha512sum, which hashes an extra LF byte that echo -n does not add.
Turn on 'Keyed mode: HMAC-SHA512' and enter a key to produce a JWT HS512-style authentication tag instead of a plain digest.
In file mode, drop a file onto the drop zone — the progress bar shows percentage and MB/s while the file is streamed through SHA-512 in chunks.
Paste the publisher's checksum into 'Compare against an expected hash' for a green match / red mismatch verdict; bare hex, base64, a sha512sum line or a BSD SHA512 (file) = hash tag are all accepted.
Frequently Asked Questions
How do I generate a SHA-512 hash of text or a file?
In text mode, type into the input box — the 128-character hex digest appears immediately and updates on every keystroke; there is no Generate button. Choose an input encoding first if your source is not UTF-8, because the digest is taken over bytes, not characters. In file mode, drop a file onto the drop zone: it is read in 4 MiB chunks and fed through a streaming SHA-512, so nothing is uploaded and nothing is held in memory in one piece. Both modes produce results identical to sha512sum, shasum -a 512 and Get-FileHash -Algorithm SHA512 on the same bytes.
What is the SHA-512 hash of an empty string?
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e, or z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg== in base64. It is the digest of zero bytes, which makes it the checksum of every empty file — sha512sum /dev/null prints exactly that value. It is worth recognising on sight: seeing it in a log usually means a pipeline hashed nothing at all, because the stream was already consumed or the download failed. Many hash tools refuse empty input; this one allows it and labels the result.
Is it safe to hash sensitive data in this tool?
Yes. The tool runs entirely in your browser: text is hashed with the native Web Crypto API (crypto.subtle.digest) and files are hashed by a WebAssembly module served from this site. Your input never reaches a server, is never logged and is never stored. You can verify that claim without trusting us: open DevTools, switch to the Network tab, hash a multi-gigabyte file and observe that no request is made while it runs. The only network activity on the page is the initial load plus the one-time WebAssembly fetch used by file mode and the multi-algorithm panel.
SHA-256 vs SHA-512 — which should I use?
SHA-256 is the default: it is what TLS certificates, JWT HS256/RS256, Git's modern object format and most protocols specify, and its 128-bit collision resistance is already unreachable. Choose SHA-512 when a spec demands it (BIP-32 key derivation, JWT HS512, some PKI hierarchies), when your keys are longer than 64 bytes and HMAC's 128-byte block helps, or when you are on 64-bit hardware and want the speed — SHA-512 works on 64-bit words and typically runs 1.2–1.5× faster than SHA-256 there, while being slower on 32-bit devices. Never use either one, alone, for passwords.
Why doesn't my UTF-16 SHA-512 match another tool's?
Almost always a byte-order mark. Many online tools silently prepend FF FE (UTF-16LE) or FE FF (UTF-16BE) before hashing, which adds two bytes and produces a completely different digest: SHA-512 of "abc" as UTF-16LE without a BOM starts add8b8154df7a734…, and with the BOM 6d821d068cd8f095…. This tool never adds a BOM unless you tick the checkbox. The second suspect is endianness — UTF-16LE and UTF-16BE hold the same characters in opposite byte order, so they never agree. The third is the encoding itself: "café" is 5 bytes in UTF-8 but 4 in Latin-1.
Why does echo "abc" | sha512sum differ from hashing abc here?
echo appends a newline. "abc" hashes to ddaf35a193617aba…, but "abc\n" — what echo actually pipes — hashes to 4f285d0c0cc77286…. Use printf '%s' abc | sha512sum or echo -n abc | sha512sum to hash three bytes, or tick this tool's 'Append a trailing newline' toggle to reproduce the four-byte version. The same class of bug bites text files: an editor that adds a final newline, or a Windows checkout storing CRLF instead of LF, changes the file's checksum without changing a single visible character.
How do I verify a downloaded file's SHA-512 checksum?
Switch to Hash File, drop the download in, then paste the publisher's checksum into the compare box — a sha512sum line (hash, two spaces, filename) or a BSD SHA512 (file) = hash tag can be pasted whole. A green verdict means the bytes are identical. One caveat is worth more than the checksum itself: a hash alone only proves the file was not corrupted in transit. If an attacker can replace the download they can usually replace the published hash too, so for real tamper protection verify the publisher's GPG signature over the SHA512SUMS file, or rely on Authenticode/codesign.
Can SHA-512 be used with a secret key (HMAC-SHA512)?
Yes — switch on 'Keyed mode: HMAC-SHA512'. HMAC (RFC 2104) nests a secret key with the message and outputs a 512-bit tag; it is what JWT HS512 signs with and what BIP-32 uses to derive hierarchical wallet keys. Its 128-byte block size accommodates long keys without pre-hashing them. Use a random key of at least 32 bytes and compare tags in constant time in production code. Never authenticate with sha512(secret ‖ message): SHA-512 is a Merkle–Damgård hash and is vulnerable to length extension. For more key formats, see the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.