Hash Generator
Generate SHA-1, SHA-256, SHA-384, SHA-512 and HMAC digests of text or a file, in hex or Base64 — computed locally with WebCrypto.
Input
0 bytesDigests
hexEnter text or choose a file to see its digests.
Verify
paste an expected digestDigests are computed with the WebCrypto API in your browser. Text, files and HMAC keys are never uploaded, stored or logged.
About the Hash Generator
Compute SHA-1, SHA-256, SHA-384 and SHA-512 digests of text or a file, in hex, Base64 or Base64URL, and HMAC digests when you supply a key. Everything runs through the WebCrypto API in your browser — the same implementation the browser uses for TLS — so files are read locally and never uploaded.
A hash is a one-way fingerprint: any input, however large, produces a fixed-length output, and changing a single bit changes roughly half the output bits. That makes it right for verifying that data is unchanged, and wrong for anything you need to reverse. It is also wrong for passwords — a fast hash is exactly what an attacker wants, which is why password storage uses a deliberately slow function like Argon2id or bcrypt instead.
HMAC is a different operation that people often reach for by mistake. It is a keyed digest, and it is not the same as hashing the key and the message concatenated together — that naive construction is vulnerable to length-extension attacks against SHA-1 and SHA-256. If you are signing a webhook or an API request, HMAC is the primitive you want.
MD5 is deliberately absent. It has practical collision attacks, WebCrypto does not implement it, and shipping a hand-rolled version would invite it to be used for the jobs it must not do.
- SHA-1, SHA-256, SHA-384 and SHA-512 computed at once, so you can compare against any published checksum
- Hex, Base64 and Base64URL output
- HMAC with a secret key, for webhook and API signature verification
- File hashing — read locally in the browser, never uploaded
- Paste an expected digest to have the matching row highlighted, compared in constant time
How to use it
- Type or paste your text, or press Hash a file to pick a file from disk.
- Choose the output encoding. Hex is the usual form for checksums; Base64 is common in HTTP headers and Subresource Integrity.
- For a keyed digest, tick HMAC and enter the secret. WebCrypto rejects an empty key, so one is required.
- Copy the digest for the algorithm you need.
- To verify a download or a signature, paste the expected value into the Verify box — the matching row turns green.
Real-world use cases
Backend & API developers
Compute an HMAC signature to debug a webhook integration, comparing it byte for byte against what the provider sent in the signature header.
DevOps & release engineers
Verify a downloaded artifact or Docker layer against its published checksum before deploying it, catching a corrupted or tampered download before it reaches production.
QA & test engineers
Generate a stable digest of a test fixture to use as a cache key or a snapshot identifier, so two runs over identical input are trivially comparable.
Security engineers
Check a file's SHA-256 against a threat intelligence report or a known-good baseline, entirely offline, without uploading a potentially sensitive sample anywhere.
Frontend developers
Generate a Subresource Integrity hash for a third-party script or stylesheet tag, so the browser refuses to execute it if the CDN ever serves something different.
Examples
SHA-256 of an empty string
(nothing)
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Worth memorising the first few characters — seeing e3b0c442 in a log almost always means an empty body was hashed by mistake.
SHA-256 of "abc"
abc
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
The standard NIST test vector. If your own implementation disagrees with this, the bug is in how you encode the input to bytes.
HMAC-SHA256
message: what do ya want for nothing? key: Jefe
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843
RFC 4231 test case 2. This is the shape of a Stripe, GitHub or Slack webhook signature.
The avalanche effect
hello hellp
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7
One character apart, and the digests share nothing. There is no notion of two hashes being close.
Common errors
| Message | Cause | Fix |
|---|---|---|
| crypto.subtle is undefined | An insecure context. WebCrypto is only exposed over HTTPS and on localhost. | Serve the page over HTTPS, or use localhost during development. |
| DataError: Zero-length key is not supported | HMAC was called with an empty key. WebCrypto refuses it rather than treating it as a key of all zeros. | Supply a key. If the secret is genuinely optional in your protocol, use a plain digest instead. |
| Webhook signature never matches | Almost always the message, not the hash: the raw request body must be signed, but a framework had already parsed and re-serialised it, changing whitespace or key order. | Capture the raw body before any JSON middleware, and confirm you are using HMAC rather than hashing key + body. |
| Digest differs from the server's for the same text | A character-encoding mismatch. Hashing UTF-16 code units, or a string with a trailing newline, gives a completely different result. | Hash UTF-8 bytes on both sides, and check for a trailing newline — echo adds one unless you pass -n. |
| Checksum mismatch on a downloaded file | Either a genuinely corrupt or truncated download, or the wrong algorithm — a SHA-1 value compared against a SHA-256 digest. | Check the digest length first: 40 hex characters is SHA-1, 64 is SHA-256, 128 is SHA-512. All four are shown here at once. |
| Two different files produce the same MD5 or SHA-1 | A deliberate collision. Both algorithms have practical collision attacks; SHA-1's was demonstrated in 2017. | Use SHA-256 or better for anything security-relevant. SHA-1 is fine only for non-adversarial checks like cache keys. |
Frequently asked questions
›Is my text or file uploaded anywhere?
No. Hashing runs entirely in your browser through the WebCrypto API. Files are read with the File API and never leave your machine — you can confirm it by hashing a file with your network disconnected. Nothing is stored or logged.
›Can a hash be reversed?
Not by inversion — the function discards information, and many inputs map to each output. What can be reversed is a guess: for short or common inputs an attacker simply hashes candidates until one matches, which is why unsalted hashes of passwords or email addresses offer very little protection.
›Why is there no MD5?
WebCrypto does not implement it, and that is the right decision. MD5 has had practical collision attacks since 2004 — two different files can be constructed to share a digest in seconds. Including it here would mean shipping a hand-rolled implementation for a function that should not be used for anything security-relevant.
›Should I use this to hash passwords?
No. SHA-256 is designed to be fast, which is precisely the wrong property: commodity hardware computes billions of candidate hashes per second. Use Argon2id, scrypt or bcrypt, which are deliberately slow and memory-hard, and always with a per-user salt.
›What is the difference between a hash and an HMAC?
A hash takes only a message, so anyone can compute it. An HMAC takes a message and a secret key, so only someone holding the key can produce or verify it — that is what makes it a signature. HMAC is also not the same as hashing key + message concatenated, a construction that is vulnerable to length-extension attacks.
›Which algorithm should I choose?
SHA-256 unless something specifies otherwise — it is the default across TLS, JWT, package registries and code signing. SHA-512 is actually faster on 64-bit hardware and is a fine choice when the digest length does not matter. Use SHA-1 only to interoperate with a legacy format such as Git object identifiers.
›Why compare digests in constant time?
A normal string comparison exits at the first differing character, so the time it takes reveals how many leading characters were correct. Against a remote verifier that is enough to forge a signature one byte at a time, so the Verify box compares every character regardless.
›Can I use the Base64 output for Subresource Integrity?
Yes — SRI attributes are a hash algorithm name followed by a hyphen and the Base64-encoded digest, e.g. sha384-<value>. Choose SHA-384 (the algorithm most SRI examples use) and Base64 output here, then prepend sha384- to what this tool produces.
Last updated