SHA-256 Hash Generator
SHA-256 maps any input to a fixed 256-bit digest, deterministically and irreversibly. It is the workhorse behind file integrity checks, content addressing, commit identifiers, and digital signatures. It is also routinely misused for passwords, where its greatest strength becomes its fatal weakness.
How to use it
- Type or paste the text you want hashed.
- The browser Web Crypto implementation computes the digest over the UTF-8 bytes.
- Copy the 64-character hex result. The input never leaves the page.
The properties that make it useful
Three guarantees do the work. It is deterministic, so the same input always produces the same digest. It is preimage resistant, so given a digest there is no feasible way to find an input that produces it. And it is collision resistant, so finding two different inputs with the same digest is computationally infeasible.
The avalanche effect is what makes those guarantees usable in practice. Changing a single bit of input changes roughly half the output bits, with no discernible relationship between the change and the result. This is why comparing the first and last few characters of a digest is a reasonable shortcut when checking a value by eye: near-misses do not occur.
Output is always 64 hexadecimal characters regardless of input size. Hashing an empty string and hashing a gigabyte both produce 256 bits.
Why this is the wrong tool for passwords
SHA-256 is designed to be fast, and hardware has made it extraordinarily fast. A single modern GPU computes billions of SHA-256 operations per second, which is why the entire Bitcoin mining industry is built on it.
Applied to passwords, that speed is the attack. An attacker holding a database of SHA-256 password hashes can test the entire contents of a common-password list in seconds and exhaust every eight-character alphanumeric password in hours.
Determinism compounds the problem. Because the same password always yields the same digest, precomputed rainbow tables work, and identical digests in a leaked database immediately reveal which users share a password.
The correct tools are Argon2id, scrypt, and bcrypt. All three are deliberately slow and salted, and the first two are additionally memory-hard, which defeats the parallelism that makes GPU attacks effective. The slowness is not a limitation to work around; it is the entire point.
Hashing is not authentication
A plain hash proves that data has not changed, provided the reader trusts the digest they are comparing against. It proves nothing about who produced the data. An attacker who can modify a file can usually modify the published hash alongside it.
HMAC closes that gap by mixing a secret key into the computation, so only someone holding the key can produce a valid tag. If you are building message authentication, use HMAC-SHA256 rather than hashing the concatenation of a secret and a message, which is vulnerable to length-extension attacks against the Merkle-Damgard construction SHA-256 uses.
One more implementation detail: compare digests with a constant-time function. A naive string comparison returns early on the first mismatched character, and the timing difference is measurable enough to let an attacker recover a valid tag one byte at a time.
Low-entropy inputs are not protected
Irreversibility is a property of the function, not a guarantee about your data. If the set of possible inputs is small, an attacker simply hashes all of them and looks up the result.
This applies to email addresses, phone numbers, national identifiers, and postcodes. Hashing an email address does not anonymise it, because an attacker with a list of candidate addresses can hash the list and match. Anonymisation requires either a secret salt the attacker does not have, or not storing the value at all.
At a glance
| Algorithm | SHA-256, via SubtleCrypto.digest |
|---|---|
| Output | 64 hexadecimal characters, 256 bits |
| Input encoding | UTF-8 |
| Transmitted | Nothing |
Frequently asked questions
Can a SHA-256 hash be reversed?
Not by inverting the function. But if the input came from a small set of possibilities, an attacker can hash every candidate and match. Irreversibility protects the algorithm, not low-entropy data.
Should I hash passwords with SHA-256?
No. It is far too fast, and a GPU tests billions of candidates per second. Use Argon2id, scrypt, or bcrypt, which are deliberately slow, salted, and in the first two cases memory-hard.
Is SHA-256 still considered secure?
Yes. There is no practical collision or preimage attack, unlike MD5 and SHA-1, both of which are broken. SHA-256 remains the standard choice for integrity and signatures.
Does hashing an email address anonymise it?
No. Email addresses come from a guessable space, so an attacker hashes a candidate list and matches. Under most privacy regimes a hashed identifier is still personal data.
Read more
Tokens, hashes, and identifiers — Why a UUID is not a secret, a hash is not encryption, and a JWT you have not verified is just a base64 string.