A hash is a function of BYTES, not of letters. So "the SHA-256 of a string" means nothing until an encoding is named — here it is always UTF-8. The peso sign is one character and three bytes, which is why this page reports both counts.
That is also behind the commonest mismatch: a trailing newline. echo hello sends six bytes, not five, so it hashed a different input. Check the byte count first whenever a value does not match one from elsewhere.
A hash and an HMAC do different jobs. A hash proves data has not changed. Anyone can compute a SHA-256, so if an attacker can alter the data they can recompute the digest to match. An HMAC needs a secret key, and that is what makes it evidence of who produced it.
Almost always a trailing newline. `echo hello` sends “hello\n” — six bytes, not five — so the two digests are of different inputs and will never match. Use `echo -n` or `printf`, or paste the text here without the newline. This page reports the byte count beside the digest so the difference is visible rather than mysterious.
UTF-8. A hash is a function of bytes, not of characters, so “the SHA-256 of a string” is meaningless until an encoding is named. It matters the moment the text is not plain ASCII: the peso sign is one character and three bytes. The page shows both counts for that reason.
A plain hash proves that data has not changed. An HMAC proves who produced it, because computing one requires a secret key. Anyone can compute a SHA-256, so a bare digest authenticates nothing — if an attacker can change the data they can recompute the digest to match.
Because SHA-256 is vulnerable to length extension: knowing the hash of a secret plus a message lets an attacker compute the hash of that secret plus a longer message, without ever learning the secret. HMAC’s nested construction is what closes it, and that is the whole reason it exists rather than being an arbitrary convention.
Both are broken for anything that depends on collisions being hard, and both are still the first thing people reach for. Offering them beside SHA-2 would present them as a matter of taste. Verifying a legacy checksum somebody else produced is a real need and it is not enough of one to ship a broken primitive here.
Nothing leaves your browser. The hash functions are written out in this site’s own calculation engine — not called over a network, and not taken from a third-party library — so the text you paste is never transmitted, logged or stored.
They are checked against the published test vectors rather than against themselves. SHA-256, SHA-384 and SHA-512 are verified against FIPS 180-4, including the million-byte case, and the HMAC construction against RFC 4231 — whose case 6 covers the rule most hand-written HMACs miss, that a key longer than the block is hashed rather than truncated.
SHA-384 is not SHA-512 truncated. They start from different initial values, so lopping 48 bytes off a SHA-512 digest gives a different and wrong answer.
In HMAC, a key longer than the algorithm block is hashed down first, never truncated. It is the single most commonly missed line in a hand-written HMAC — and missing it lets two different long keys produce the same MAC. RFC 4231 case 6 exists to catch exactly that, and this implementation is tested against it.
Computed in your browser and never transmitted. The implementations are verified against the FIPS 180-4 and RFC 4231 test vectors, but a digest is only as meaningful as the bytes you gave it — check the byte count if a value does not match one from elsewhere. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
