Hash & HMAC Generator
SHA digests via the Web Crypto API. Files are read locally and never uploaded.
chevron_leftchevron_right
HMAC
SHA-1
—
SHA-256
—
SHA-384
—
SHA-512
—
Produce SHA-1, SHA-256, SHA-384, SHA-512 and HMAC digests for text or a file, using the browser’s native Web Crypto implementation.
A hash is a fingerprint, not encryption: it cannot be reversed, and the same input always produces the same digest. That makes it the right tool for verifying that a download arrived intact or that two files are identical, and the wrong tool for storing passwords — a raw SHA-256 of a password is broken by a lookup table in the time it takes to read this sentence.
SHA-1 is offered because you will still meet it in old checksums, and it should not be used to protect anything: practical collisions have existed since 2017. SHA-256 is the sensible default; SHA-384 and SHA-512 are here for the protocols that ask for them. MD5 is absent — the Web Crypto API this runs on does not implement it, which is the correct answer for a hash nobody should be choosing today. HMAC is the separate case where a shared secret is mixed into the digest, which is how webhook signatures from services like Stripe or GitHub are verified.
Two properties are what make a hash useful, and both are worth stating plainly. It is deterministic — the same input always gives the same digest, on any machine, in any language — and it is avalanching, so changing a single bit of the input changes roughly half the bits of the output. That is why comparing two digests is a reliable way to tell whether two files are byte-identical, and why a digest that differs tells you nothing at all about how much the files differ.
The practical use is verification. A published SHA-256 next to a download exists so you can confirm the file arrived intact and came from where it claims to; a mirror that serves a corrupted or modified copy produces a different digest immediately. This matters most for installers and disk images, where the failure mode of a silently truncated download is an install that half works. Hashing here happens in the page through the Web Crypto API, so a file never leaves the machine — which is what makes it usable for something you would not upload to a checksum site.
HMAC is a different construction and answers a different question. A plain hash proves integrity; anyone can compute one, so anyone can also recompute it after changing the data. HMAC mixes in a shared secret, so a valid digest proves that whoever produced it holds the key. That is the mechanism behind webhook signatures from services such as Stripe, GitHub and Slack: the request body is hashed with a secret you both know, and comparing the result to the header they sent is how you establish the request is genuinely theirs rather than a replay someone assembled.
A digest covers every byte, which includes the ones nobody thinks about. A trailing newline at the end of a file changes the hash; so does a file transferred in text mode between Windows and Unix, because the line endings were rewritten in transit and the content is no longer byte-identical even though it reads the same. When a published checksum does not match a downloaded file, a corrupted download is one explanation and a helpful tool that normalised the line endings is another. Hashing the file rather than its pasted contents avoids the whole category, which is why the file input is there.
No. Web Crypto deliberately omits MD5 because it is cryptographically broken. If you need it to match a legacy system, use a server-side library.
No. Files are read locally and hashed in the browser; nothing is transmitted.
Almost always a text encoding or line-ending difference. This tool hashes UTF-8 bytes exactly as given, so a trailing newline changes the result.