SHA-512 has no decrypt, and the sites offering one are reading from a list
Encryption keeps the original around in scrambled form, waiting for a key. SHA-512 does not. It reads your input, mixes it through 80 rounds, and hands back 64 bytes. A one line email and a 4 GB disk image both come out as the same 128 hex characters, so the original cannot be sitting inside the digest. Reversing it would mean recovering the disk image from 64 bytes.
Type password into a site advertising SHA-512 decryption and it returns password within a second. Type a passphrase your team invented last Tuesday and it returns nothing at all. The difference tells you exactly what happened: the first value was already in a precomputed table, and the second was not. No maths was reversed either time.
What people usually mean by decrypt
Almost every visitor arriving on a "SHA512 decrypt" search wants one of three things, and each has a real answer.
| What you are trying to do | The working approach | Where on this page |
|---|---|---|
| Check whether a password matches a stored digest | Hash the candidate and compare the two digests. This is what every login system does, since none of them recover the stored password either. | Verify tab |
| Confirm a download was not altered | Hash the file and match it against the digest the publisher listed. | File tab |
| Protect a payload so only a keyholder reads it | You want encryption, not a hash. AES with a key you control does this. A digest never comes back. | Encryption and Decryption tool |
A fourth case turns up in support tickets: someone inherited a database of SHA-512 password digests and wants the plaintext back. The answer there is a migration, not a recovery. Rehash on next login into bcrypt or Argon2 and keep the old column only long enough to catch stragglers.
Why the lookup sites work at all
SHA-512 is deterministic, so hunter2 produces the same digest on every machine, every time, forever. Someone hashed a few billion common strings once and stored the pairs. A lookup site queries that table. It breaks nothing about the algorithm, and it stops working the moment your input is unusual.
Salt kills the table
Store sha512(salt + password) with a distinct random salt per user and the attacker's precomputed table is worthless, because they would need one table per salt. This is why every password scheme since the 1970s stores a salt beside the digest.
Speed is the other half
Salt stops precomputation but not brute force. A consumer GPU runs billions of SHA-512 operations per second, so a salted six character password still falls in minutes. Slow hashes exist to remove that advantage.
HMAC-SHA512 is the part that behaves like a key
The HMAC tab is the closest thing here to what people picture when they say encrypt with SHA-512. Feed it a secret and a message and the output changes completely if either one changes by a byte. Anyone without the secret cannot produce a matching tag, even knowing the full message.
Two details about the key trip people up when they compare output across languages:
- Long keys get shortened. SHA-512 processes 128 byte blocks, so HMAC hashes any key longer than 128 bytes down to 64 bytes before use. A 200 character API secret and its SHA-512 digest give identical tags.
- Short keys get padded with zeros. A one character key is legal and produces a valid tag. It is also close to useless, since guessing it takes no time. Use at least 32 random bytes for anything real.
Webhook signatures are the common use. Stripe, GitHub, and most payment providers sign the raw request body with HMAC and put the tag in a header. Paste the exact body and your signing secret here to see whether your handler is reading the same bytes the sender signed. A mismatch is usually a framework that reparsed and re-serialized the JSON before your code touched it.
The encoding row changes the answer
The Input row above is not cosmetic. It decides what bytes the hasher receives.
Take 4142. Read as UTF-8 it is four characters, the digits 4, 1, 4, 2. Read as Hex it is two bytes, A and B. Two different inputs, two unrelated digests. Switch the Input row between UTF-8 and Hex with 4142 in the box and watch the output change entirely.
This is behind most reports of a digest not matching between a browser tool and a backend. The backend hashed decoded bytes while the browser hashed the printable text of those bytes, or the other way around. Match the encoding before you suspect the algorithm.
The Output row is a formatting choice made after hashing, so the underlying 64 bytes are the same either way. Hex gives 128 characters, Base64 gives 88 including the two padding marks. Base64 is what appears in HTTP headers and JWT related fields where length matters.
Checking a file against a published digest
Project release pages list digests so you can tell a mirror served the real file. Drop the download into the File tab and compare visually, or use the command line, which is faster for anything past a few hundred megabytes:
sha512sum ubuntu-24.04.iso
shasum -a 512 ubuntu-24.04.iso # macOS
certutil -hashfile ubuntu-24.04.iso SHA512 # WindowsOne warning about this check. A digest fetched from the same page as the file proves the transfer was not corrupted, and nothing more. Whoever replaced the file could replace the listed digest on the way past. Signed checksum files, where a GPG signature covers the SHA512SUMS file, are what turns a corruption check into a tamper check.
Matching this page in your own code
All three snippets produce the same 128 hex characters as the Hash tab with UTF-8 input:
// PHP
$digest = hash('sha512', $text);$tag = hash_hmac('sha512', $body, $secret);$file = hash_file('sha512', '/path/to/archive.tar.gz');if (hash_equals($tag, $headerValue)) { }# Python
import hashlib, hmac
digest = hashlib.sha512(text.encode()).hexdigest()tag = hmac.new(secret.encode(), body.encode(), hashlib.sha512).hexdigest()if hmac.compare_digest(tag, header_value):pass # trustedShell users hit one reliable trap. echo appends a newline, so the digest below is of abc\n rather than abc, and it will never match what you typed into the box above:
echo abc | sha512sum # hashes 4 bytes: a b c \n
printf %s abc | sha512sum # hashes 3 bytes, matches this pageBoth hash_equals and compare_digest exist for a reason worth knowing. A plain == on strings stops at the first differing character, so the time it takes leaks how many leading characters were correct. Against a remote attacker probing a signature, that timing is enough to rebuild the tag byte by byte. The comparison in this page is a plain string check, which is fine in a browser where you are checking your own data, and wrong in a server handling untrusted input.
Do not store passwords as a bare SHA-512
SHA-512 was designed to be fast. That is the correct goal for verifying a Linux ISO and the wrong one for storing a password, because speed belongs to the attacker as much as to you. Current hardware runs SHA-512 at billions of guesses per second against a leaked table, and a salt does not slow that down.
Use bcrypt, scrypt, or Argon2id. All three are deliberately slow, take a work factor you raise as hardware improves, and handle salting themselves. In PHP that means password_hash($pw, PASSWORD_DEFAULT) and nothing more.
One source of confusion: the $6$ entries in /etc/shadow on Linux are labelled SHA-512, and they are not a plain digest. That format is 5000 rounds of SHA-512 with a salt, a scheme from 2007. Hashing a password once here will never reproduce a $6$ line.
Where this page stops
- No decryptionThere is no mode that recovers input from a digest, here or anywhere. If you need reversible protection, encrypt instead of hashing.
- Verify is hex onlyThe Compare tab reads 128 hex characters and treats your text as UTF-8. Base64 digests and the Hash tab's encoding toggles do not carry over to it.
- HMAC output is hexThe Base64 toggle applies to the Hash tab. For a Base64 tag, hex to Base64 conversion is a separate step.
- Files load into memoryThe whole file is held in the tab before hashing, so a large ISO can exhaust the tab well before it finishes. Use sha512sum for anything past a gigabyte or so.
- Comparison is not constant timeFine for checking your own values in a browser. Copy the approach into a server that validates signatures and you have introduced a timing side channel.
- SHA-512 onlyNo SHA-512/224, SHA-512/256, or SHA-3. Those are separate algorithms with separate pages, not options on this one.
Everything runs in the page through the CryptoJS library loaded with it. No text, key, or file leaves your machine, which the network panel will confirm while you hash. The library itself is fetched from a CDN when the page opens, so the first load needs a connection and the hashing afterwards does not.
