Web Crypto API · nothing leaves your browser
Hash & HMAC Generator
SHA-1, SHA-256, SHA-384, SHA-512 and MD5 of any text or file, keyed HMACs, and a constant-time checksum verifier — computed by your browser's own cryptography, not by a server.
SHA-1, SHA-256, SHA-384, SHA-512 and MD5 of any text or file, keyed HMACs, and a constant-time checksum verifier — computed by your browser's own cryptography, not by a server.
| MD5 | ||
|---|---|---|
| SHA-1 | ||
| SHA-256 | ||
| SHA-384 | ||
| SHA-512 |
A cryptographic hash turns input of any size into a fixed-size digest — 256 bits for SHA-256 — such that the same input always gives the same digest, a one-bit change anywhere gives a completely different one, and finding two inputs with the same digest is computationally infeasible. That last property is what separates a cryptographic hash from a checksum like CRC32, and it is the one MD5 and SHA-1 have lost.
A release page publishes sha256sum values so you can confirm the file you received is the file they built. Drop the file here, paste the published digest into the verifier, and the comparison is done in the page. If the digests differ the file is corrupt or altered; if they match, you have the file the publisher hashed — which only proves anything if you trust the page you copied the digest from.
Stripe, GitHub, Slack and most payment providers sign each webhook with an HMAC over the raw body using your shared secret. Paste the exact body and the secret and compare the HMAC-SHA256 here with the header they sent. The most common failure is hashing a re-serialised body rather than the raw bytes — a single reordered key or trailing newline changes everything.
Git names every object by its SHA-1 (moving to SHA-256), and object stores, package managers and build caches use a digest as the key. Hashing here lets you confirm what key a blob would receive, or check whether two files that look identical actually are.
None of these functions is suitable for storing passwords. They are fast by design, and a GPU computes billions of SHA-256 values per second, so a leaked table of plain hashes falls to a dictionary attack in hours. Password storage needs a deliberately slow, salted, memory-hard function: Argon2id, scrypt or bcrypt. This page will not offer one, because doing it in a browser page would suggest it is fine to do it there.
An HMAC (RFC 2104) is a hash computed in a specific way over a secret key and a message. Anyone can compute a plain SHA-256 of a message, so a plain hash proves nothing about who sent it; an HMAC can only be produced by someone who holds the key, which turns it into an authentication tag. The construction — hash the key XOR an inner pad concatenated with the message, then hash the key XOR an outer pad concatenated with that — exists because naively hashing key + message is vulnerable to a length-extension attack on every Merkle–Damgård hash, SHA-256 included. Use the construction, never the naive concatenation.
When a key is entered above, every row switches from a plain digest to an HMAC with that key. The key is handled as UTF-8 text. If your integration hands you a key as hex or base64, decode it first; a key of the string "a1b2c3" and a key of the bytes 0xa1 0xb2 0xc3 produce different tags, and that mismatch is the second most common webhook signature bug.
| Algorithm | Digest | Collision resistance | Use it for |
|---|---|---|---|
| MD5 | 128 bits | Broken — collisions in seconds on a laptop | Matching legacy checksums, ETags, non-security dedup keys. Never for signatures or integrity against an adversary. |
| SHA-1 | 160 bits | Broken — practical chosen-prefix collisions since 2020 | Reading existing Git object ids and old certificates. Do not choose it for anything new. |
| SHA-256 | 256 bits | Sound | The default. Downloads, signatures, HMACs, content addressing. |
| SHA-384 | 384 bits | Sound; resists length extension | When a 384-bit output is mandated (some TLS suites, FIPS profiles). |
| SHA-512 | 512 bits | Sound | Faster than SHA-256 on 64-bit CPUs for large inputs; larger digest. |
MD5 is not provided by the Web Crypto API at all — browsers dropped it deliberately — so the value shown here comes from a small implementation of RFC 1321 included in the page and checked against the RFC's own test vectors. It is here because you will still meet MD5 in the wild: old download pages, Amazon S3 ETags for single-part uploads, database migration checksums, and UUID v3. Being able to check one is not the same as being allowed to choose one.
The SHA family is computed by crypto.subtle.digest(), and HMACs by crypto.subtle.sign() with an imported HMAC key. Both are native browser code, which is why a 200 MB file hashes in a few seconds. A file is read into memory in full before hashing, because the Web Crypto API has no streaming digest; that puts a practical ceiling around a gigabyte depending on the device. The verifier compares digests with a fixed-time loop over the full length rather than a string equality, and treats case and surrounding whitespace as irrelevant so a checksum copied from a web page with a stray newline still matches.
No. Hashing is done by the Web Crypto API built into your browser, and the MD5 implementation is JavaScript in the page. There is no request to any server. You can verify this in the Network tab of your browser's developer tools, or by loading the page and then disconnecting from the internet before hashing a file.
Almost always the bytes differ even though the characters look the same. A trailing newline added by an editor, Windows CRLF line endings, a UTF-8 byte-order mark, or a different Unicode normalization form all change the digest. Hash the exact bytes on both sides — for a file, hash the file rather than its pasted contents; for text, check the byte count shown under the input against what your server sees.
No. A hash is one-way: the digest is a fixed 256 bits regardless of input size, so infinitely many inputs map to each digest and there is no inverse function. What attackers do instead is guess: precompute digests of likely inputs (a dictionary, or every string up to eight characters) and look yours up. That is why a fast hash of a password is not protection, and why salts and slow functions exist.
A hash has no key: anyone can compute it, so it proves integrity against accidental change but not against a deliberate one, since an attacker who alters the message can recompute the hash too. An HMAC mixes a secret key into the computation using the RFC 2104 construction, so only a holder of the key can produce a valid tag. Use a hash to detect corruption; use an HMAC to authenticate a message from a party you share a secret with.
Three usual causes. The body you pasted is not the raw body: it was pretty-printed, re-serialised or had whitespace changed, and the HMAC covers exact bytes. The key was given to you as hex or base64 and you used the encoded string as the key instead of decoding it to bytes. Or the provider signs something other than the bare body, such as a timestamp joined to the body with a dot (Stripe) or a version prefix. Check the provider's documentation for what exactly goes into the signature.
No. SHA-256 and its relatives are designed to be fast, which is the opposite of what password storage needs. Use Argon2id, scrypt or bcrypt through a maintained library on the server, with a per-user random salt. A fast hash of a password, even salted, can be attacked at billions of guesses per second on commodity GPUs.