SHA-256 and SHA-512 both run through crypto.subtle.digest, the browser's native Web Crypto API — the same audited implementation the browser itself relies on, not a JavaScript reimplementation. Output is 64 hex characters for SHA-256, 128 for SHA-512.
When your hash doesn't match the published one
SHA-256 is deterministic across every correct implementation, forever — that is the whole basis of publishing a checksum next to a download. So when a hash refuses to match, the input differs, and the usual culprit is invisible: a trailing newline. echo "hello" | shasum -a 256 hashes six bytes (hello plus \n) and disagrees with this page, which hashes exactly the visible characters; printf agrees with it. The other classic mismatch is encoding — this tool encodes input as UTF-8 before hashing, so accented text matches other UTF-8 tools but not anything hashing UTF-16, a recurring PowerShell surprise.
Three things SHA-256 is not
It is not encryption — there is no key and no way back, only guessing inputs. It is not password storage — it is fast by design, and that speed hands attackers billions of guesses per second against a leaked table; bcrypt exists specifically to remove that advantage. And it is not authentication — anyone can hash anything, so a bare digest proves integrity, not origin. Proving who produced a message needs a key in the loop, which is HMAC's job.
The HMAC tool is the keyed version of this page for when integrity alone is not enough, and bcrypt is the correct answer whenever the input is a password.