SHA256 Hash Generator_
SHA-256 for text or a file, computed by the browser's own Web Crypto implementation rather than one shipped in the page. It is the digest behind every HTTPS certificate you have ever been served, every Bitcoin block, and the integrity check on most software you install.
It is also the one algorithm here that nobody has broken. Which makes its single structural quirk worth knowing: the digest is the internal state at the end of the message, so anybody holding one can carry on hashing from it. That is a real attack with a one-word fix, and the fix is the second button above.
—Authenticating a message with a shared secret? A plain digest of key and message together can be extended by somebody who never saw the key. Switch to HMAC.
- Input
- Text as UTF-8, or a local file read in the page. In HMAC mode, a secret key as well — the key authenticates the message and is never part of it.
- Output
- Sixty-four hexadecimal characters. In HMAC mode the same length, produced by a keyed construction rather than a bare digest.
- Processing
- crypto.subtle from the browser, which is a native implementation the vendor maintains and audits. Nothing here reimplements SHA-256, because there is no reason to and every reason not to.
- Limits
- A digest proves the bytes match. It proves nothing about who produced them — that needs a key, which is what HMAC and signatures are for.
- Length extension, and why HMAC exists
- SHA-256 publishes its full final state as the digest, so given H(secret ‖ data) and the length of the input, an attacker can append their own data and compute a valid digest for the longer message without ever learning the secret. Naive MACs built as a plain digest of key-then-message are forgeable for exactly this reason. HMAC hashes twice with two derived keys so the output is not a resumable state, and SHA-384 escapes the problem another way — it is SHA-512 with half the state thrown away.
The unbroken one, and its one sharp edge
Where SHA-256 already is
It is the default almost everywhere that matters. Every TLS certificate in your browser's trust store is signed over a SHA-256 digest. Bitcoin's proof of work is SHA-256 applied twice, and its block identifiers are the same function. Linux packages, container images and language registries verify downloads with it. JSON Web Tokens signed with HS256 or RS256 are hashing with it. Git is migrating its object names to it. If you are choosing a hash in 2026 and have no specific reason to choose otherwise, this is the one.
The digest is the machine's state, and that is exploitable
SHA-256 processes a message in 512-bit blocks, carrying eight 32-bit words of state from one block to the next, and at the end it prints that state. Nothing is hidden. So if you know H(m) and the length of m, you can load that state into your own SHA-256, keep feeding it whatever you like, and produce a correct digest for m followed by padding followed by your data — without knowing a single byte of m. That is a length-extension attack, and it works on SHA-256, SHA-512, SHA-1 and MD5 alike.
Which breaks the obvious way to authenticate a message
The intuitive design is to share a secret and send digest = SHA256(secret + message) alongside the message, so a recipient can recompute it. Length extension defeats this exactly: an attacker who sees one valid pair can append &admin=true and compute a digest that verifies, never having seen the secret. Flickr's API was broken this way in 2009. HMAC solves it by hashing twice with two keys derived from yours, which is why every serious protocol specifies HMAC rather than concatenation — and why the toggle above exists.
SHA-384 sidesteps it entirely
SHA-384 is SHA-512 run with different starting constants and then truncated to 384 bits. The 128 bits it discards are part of the internal state, so an attacker never learns the full state and cannot resume the computation. It is a slightly odd reason to pick an algorithm, and it is a real one — as is SHA-3, which avoids the whole family of attacks by being built differently. Neither is necessary if you are using HMAC, which is the ordinary answer.
Still not a password function
Being unbroken is not the same as being appropriate. SHA-256 is engineered to be fast — that is a feature for verifying a gigabyte and a liability for storing a secret, because the same speed lets an attacker with a stolen table try billions of candidates a second. Adding a salt fixes the lookup-table problem and not the speed one. Password storage needs a function that is slow by design and tunable as hardware improves: bcrypt, scrypt or Argon2.
Digest, or keyed digest
- 01Type or paste a message and the SHA-256 digest appears immediately. Choose a file instead if you are verifying a download.
- 02To check a download, paste what the publisher listed into the field below the digest. Sixty-four hex characters, and case does not matter.
- 03Press HMAC when you are authenticating rather than checksumming. A key field appears, and the output becomes a keyed digest that cannot be extended.
- 04Keep the key out of the message field. In HMAC the two are separate inputs on purpose, and putting the secret in the message is the mistake the whole construction exists to prevent.
Verifying a package or an ISO
Distributions and language registries publish SHA-256 alongside downloads. Matching it means the bytes are the ones the publisher hashed.
e3b0c44298fc1c149afbf4c8996fb924 27ae41e4649b934ca495991b7852b855
Identical → install it. Different → the file is not what was published.
Signing a webhook the correct way
The sender and receiver share a secret. Hashing the secret and body together is forgeable; HMAC is not, which is why every webhook specification names it.
sig = SHA256(secret + body) // extendable — an attacker can append
sig = HMAC-SHA256(secret, body) // two derived keys, no resumable state
A content address that will not collide
Naming a blob by its digest gives deduplication and integrity in one step. This is how container layers, Git objects and content-addressed stores work.
the bytes, whatever they are
sha256:ba7816bf8f01cfea414140de5dae2223…
What a Bitcoin block identifier is
Proof of work is SHA-256 applied twice to a block header, repeated with different nonces until the digest starts with enough zeros.
version | prev hash | merkle root | time | bits | nonce
SHA256(SHA256(header)) 0000000000000000000…
Choosing between the SHA family
| Algorithm | Digest | Extendable | When to prefer it |
|---|---|---|---|
| SHA-256 | 64 hex characters | Yes | The default. Certificates, package integrity, content addressing, JWT signatures. Use HMAC when a key is involved. |
| SHA-384 | 96 hex characters | No | When you need a raw digest of secret-plus-message and cannot use HMAC. Truncation hides the state that an attack would need. |
| SHA-512 | 128 hex characters | Yes | Works on 64-bit words and 1024-bit blocks, so it outruns its shorter sibling on modern servers despite the longer output. Same extension caveat. |
| HMAC-SHA256 | 64 hex characters | No | Any time a shared secret authenticates a message: webhooks, API signatures, cookies, tokens. |
| SHA-1 | 40 hex characters | Yes | Legacy compatibility only. Collisions have been demonstrated with real files. |
The extendable column is computed rather than typed: SHA-384 is the only entry here that discards part of its internal state before printing, and the test suite asserts exactly that split.
Using SHA-256 without the sharp edge
- Reach for HMAC the moment a key enters the picture. Concatenating a secret with a message and hashing the result is the specific thing length extension defeats.
- Compare digests with a constant-time function in your own code. Reading them character by character leaks timing information about where the mismatch is.
- Publish checksums somewhere other than beside the download when it matters. Anyone who can replace the file can usually replace the number next to it.
- Prefer SHA-512 over SHA-256 on 64-bit servers if throughput matters — it processes larger blocks and is measurably quicker despite the longer output.
- Do not truncate a digest to save space unless you have thought about the birthday bound. Cutting SHA-256 to 64 bits gives collisions at around four billion items, which is a smaller number than it sounds.
Assumptions about SHA-256 that do not hold
A plain digest is not a message authentication code
SHA256(secret + message) looks like one and is forgeable through length extension. Use HMAC, which exists precisely because this design is intuitive and wrong.
Unbroken does not mean suitable for passwords
Speed is the whole problem. A graphics card works through candidate passwords in bulk, so soundness of the algorithm buys nothing — what you need is a function tuned to be slow, with a cost parameter you raise as hardware improves.
SHA-256 is not encryption and produces no ciphertext
There is no key and no decryption. Tools offering to "decrypt SHA-256" are searching precomputed tables, which finds common inputs and nothing else.
Publishing the digest beside the file proves very little
Publisher and file travelling together means one compromise covers both. The checksum is evidence about transmission, not about origin — for origin you want a signature over the digest, which is what package managers actually verify.
Implementation, construction and keying
- Source
- crypto.subtle.digest, the browser's native implementation. Shipping a JavaScript SHA-256 would add an audit surface and no capability.
- Construction
- Merkle–Damgård over 512-bit blocks with a 256-bit state, printed in full at the end. That full disclosure is what makes length extension possible and why HMAC is specified separately.
- HMAC
- crypto.subtle.sign with an imported raw key, verified in the test suite against RFC 4231 — the printable test case, so the expected value can be checked against the document directly.
- Verified against
- The published digests of the empty string and of "abc", plus a fixed-length check across inputs from zero to a hundred thousand characters.
- File handling
- Uploads are read inside the page with the browser File API and are never transmitted; Download writes out what is already in the tab.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about SHA-256
Is SHA-256 secure in 2026?
Yes. There is no practical collision or preimage attack, and it remains the default for certificates, package integrity and signatures. Its one structural quirk is length extension, which affects a specific misuse rather than the algorithm itself, and HMAC is the standard answer.
What is a length extension attack?
SHA-256 prints its full internal state as the digest, so somebody holding a digest and the input length can resume hashing from it and produce a valid digest for a longer message they append to. They never learn the original input. It breaks any scheme where a plain digest of secret-plus-message is used as an authentication tag.
What is HMAC and when do I need it?
A keyed construction that hashes twice with two keys derived from yours, so the result is not a resumable state. You need it whenever a shared secret is meant to prove a message is genuine — webhooks, API request signing, signed cookies. Concatenating the secret with the message and hashing once is the design HMAC replaces.
Can SHA-256 be decrypted or reversed?
No. It has no key and discards information, so there is nothing for a reverse function to work with. Anything advertising SHA-256 decryption is running a search: it has hashed a very large dictionary in advance and checks whether your digest appears in it. Short predictable inputs turn up; a strong secret never will.
Should I use SHA-256 for passwords?
No, and not because it is weak. It is fast, and fast is exactly wrong for password storage — an attacker with a stolen database works through candidates in bulk on a graphics card. Reach instead for bcrypt, scrypt or Argon2 — slow by construction, with a cost you raise as hardware improves.
What is the difference between SHA-256 and SHA-512?
Digest width, block size and internal word size. SHA-512 works on 64-bit words and larger blocks, which makes it genuinely faster on 64-bit hardware despite producing twice the output. Both share the same construction and both are extendable; SHA-384 is SHA-512 truncated, and the truncation is what makes it resist extension.
Why does Bitcoin hash twice?
Proof of work applies SHA-256 to the block header, then applies it again to that result. The double application is widely understood as a defence against length extension in the original design, and it has stayed because the network depends on the exact function.
How long is a SHA-256 hash?
256 bits, printed as sixty-four hexadecimal characters, regardless of how much data went in. A digest twice that length came from SHA-512, and one at forty characters from SHA-1.
Is my text or file uploaded?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.