Hash vs Encryption — One-Way Digests Are Not Locks
On this page
Hash output and ciphertext both look like noise. That is why people say they “encrypted it with SHA-256.” They did not. They hashed it.
Hashing is a one-way fingerprint. Same input, same digest. You cannot recover the original from the digest alone.
Encryption is a reversible lock. Ciphertext without the key should stay unreadable. With the key, you get the plaintext back.
This page owns the hash-versus-encrypt contrast — including “is hashing encryption” and “SHA-256 encryption.” The algorithm picker is which hash function should you use. The encoding lecture is Base64 isn’t encryption. When you just need a digest, use the hash calculator. Nothing is uploaded. There is no signup.
Same “scrambled look,” different jobs
A SHA-256 hex string and an AES ciphertext both look like random characters. The jobs are different.
Hashing answers: is this the same data? Publish or store a digest, hash again later, and compare. That is integrity — a fingerprint or download checksum. The digest is meant to be seen.
Encryption answers: who is allowed to read this? Plaintext becomes ciphertext so only a key holder can recover it. That is confidentiality. The ciphertext is meant to stay opaque without the key.
A hash does not hide a guessable input. Encryption does not give you a stable public fingerprint. Using one for the other job is the whole confusion.
| Hashing | Encryption | |
|---|---|---|
| Job | Integrity / fingerprint | Confidentiality |
| Reversible? | No | Yes, with the key |
| Needs a secret? | No (unless HMAC) | Yes — a key |
| Output size | Fixed (SHA-256 = 32 bytes / 64 hex chars) | Input size plus overhead |
| Same input again | Same digest | New ciphertext if the IV/nonce changes |
| Typical use | Checksums, content IDs | Secrets at rest or in transit |
If someone who can see the output should not recover the input, you wanted encryption — or a slow password KDF, below. If they should check the input later, you wanted a hash.
Hashing is one-way
A cryptographic hash takes any input — a word, a file, a disk image — and produces a fixed-length digest. SHA-256 always returns 32 bytes, written as 64 hexadecimal characters. SHA-512 returns 64 bytes. The input can be a byte or a gigabyte; the output width does not grow.
Three properties matter in practice:
- Deterministic. Same bytes, same digest — how you verify a download against a publisher’s SHA-256.
- Fixed size. You can store and compare a digest without knowing how large the original was.
- One-way for practical purposes. Given only a SHA-256 digest, you cannot reconstruct the input. There is no “decrypt SHA-256” step.
“One-way” is not “secret.” If the input is a common password or a short known string, an attacker hashes guesses until one matches. The digest is public-safe as a fingerprint. It is not a vault.
Collision resistance and preimage resistance are why SHA-256 is the usual security default. MD5 and SHA-1 are broken for security hashing — collisions can be manufactured — but still fine as non-security checksums. See which hash function and why MD5 still won’t die.
Encryption is reversible with a key
Encryption has a second input: the key. Plaintext plus key becomes ciphertext. Ciphertext plus the same key (or the matching private key, for public-key schemes) becomes plaintext again. Without the key, the ciphertext should stay unreadable.
That reversibility is the point. You encrypt a file so you can decrypt it later. A hash cannot do that job. If you “SHA-256 your notes to keep them private,” you have destroyed the notes and kept a fingerprint.
Modern symmetric modes such as AES-GCM also take an IV or nonce — a unique value per encryption so the same plaintext does not produce the same ciphertext twice. Treat that as part of the scheme, not as a homemade extra. Do not invent a hash-then-XOR or “AES in a loop.” Use a maintained library or a tool designed for secrets (age, libsodium, a cloud KMS). This page will not give a recipe.
Encoding is a third job. Base64 makes binary printable and is reversible with no key. That mix-up is already covered on Base64 isn’t encryption.
Where people mix them up
The phrases show up in tickets and search bars: “encrypt with SHA-256,” “SHA-256 encryption,” “is hashing encryption?” Same scrambled look. Wrong primitive.
Calling a hash “encryption.” sha256("hello") is not a lock.
Anyone can hash hello and see the same digest. There is no key to
withhold. If the input is guessable, the digest is a confirmation, not
a concealment.
Storing passwords as a raw SHA-256 (or MD5) digest. A fast hash is the wrong tool. An attacker who gets the digest list can hash guesses quickly. A salt stops rainbow tables; it does not make SHA-256 slow. Use a slow, salted KDF — argon2id, bcrypt, or scrypt — not plain SHA-256. That decision tree is on which hash function.
Treating a hash as a secret. A published SHA-256 of a file is a feature: testers can verify the download. A published SHA-256 of an API key — or of an email in a log — is a checkable fingerprint. Anyone who can guess the input can match the digest. If the value must stay confidential, encrypt it or keep it off the wire. If you only need to detect change, hash it and publish the digest.
Related but not the same: salts and HMAC
Two extras get folded into “we hashed it” and then treated as encryption. They are not.
A salt is extra data mixed into a hash so two users with the same password do not get the same stored digest. It defeats rainbow tables. It does not hide the password from an offline guesser, and it does not make the function reversible. Salt ≠ encryption.
HMAC (hash-based message authentication) takes a key and a message and produces a tag. HMAC-SHA256 proves “this message was not altered and the sender knew the key.” That is authenticity and integrity, not confidentiality. The message can still be readable. JWT HS256 is HMAC-SHA256 under the hood — decode and verify that on jwt.tooljo.com. HMAC is a keyed hash. It is still not encryption. For the decision tree, see which hash function.
This page only answers whether you wanted a digest or a lock.
Hash text or a file in the browser
The job this host is built for is integrity: hash text or a file, then compare it to an expected digest.
Paste a string or drop a file on hash.tooljo.com. You get MD5, SHA-1, SHA-256, SHA-384, and SHA-512 side by side, as hex, Base64, or Base64url. Paste a publisher’s checksum into the compare field to see whether your copy matches.
SHA-1 / SHA-256 / SHA-384 / SHA-512 use the browser’s
crypto.subtle.digest (Web Crypto). MD5 is computed by a local
JavaScript implementation — Web Crypto does not expose it. Nothing
leaves your device. There is no upload and no account.
Use it to verify a download or see what “SHA-256 encryption” actually produces: a digest you cannot reverse. If you needed a lock, you needed a key — and a different tool.