A hash squeezes data of any length into a short fixed-length value, one way only. The same input always produces the same hash, and changing a single character produces a completely different one. That property lets you check whether a file survived a download intact, or tell whether two pieces of data are identical without comparing them byte by byte.
This tool computes MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC32 at once. The SHA family and HMAC run on the browser's built-in Web Crypto at native speed; only MD5 and CRC32, which Web Crypto does not offer, are implemented here directly. Files are read inside the browser and never uploaded.
How to use
- Choose text or a file — Switch between text and file at the top. Text is hashed as you type; a file is read in full the moment you select it. Either way the bytes stay in browser memory and never touch the network.
- Match the notation — Use uppercase and colon separated to match the format you are comparing against. Certificate fingerprints and network device output usually appear as uppercase with colons, so lining up the notation first saves squinting.
- Compare against a published checksum — Paste the checksum from a download page into compare with expected value and the matching algorithm's row gets a badge. Case, colons and whitespace are ignored, so you can paste it exactly as you found it.
- Sign with HMAC — Enter a secret in the HMAC panel to compute a signature. Useful for verifying a webhook signature by hand or checking what your own signing code should be producing. The secret stays in the browser as well.
Frequently asked questions
Can I use these to store passwords?
No. Every algorithm here, SHA-256 included, is designed to be fast, and speed is exactly what you do not want for passwords. A modern GPU computes billions of SHA-256 hashes per second, so cracking common passwords from a leaked hash list takes minutes.
Passwords need bcrypt, scrypt or Argon2 — functions deliberately made slow and memory-hungry. They also handle per-user salting for you and let you raise the cost factor as hardware gets faster.
Why is MD5 labelled "not for security"?
Because you can construct two different inputs with the same MD5 hash. The attack was published in 2004 and now runs in seconds on a laptop. SHA-1 joined it in 2017 when a real collision was demonstrated.
"Broken" does not mean useless everywhere, though. For detecting accidental corruption during transfer, building cache keys or finding duplicate files — situations with no adversary — both are still perfectly serviceable. Avoid them only where someone might try to forge a match.
My hash differs from the one on the download page.
Check which algorithm the page published. Comparing their SHA-256 against your MD5 will obviously never match.
If the algorithm is right and it still differs, the file really is different. The download may have truncated, been silently decompressed, or been a different build. Browsers sometimes un-gzip a file on save, so compare file sizes first — a size mismatch settles it immediately.
Why is CRC32 so much shorter?
CRC32 is a checksum rather than a hash, and produces only 32 bits — eight hex characters. It exists to catch accidental bit errors in transit, not to distinguish arbitrary data.
With only about 4.3 billion possible values, accidental collisions are easy to hit. That is fine for its actual job inside zip archives and PNG chunks, where it is checked constantly and needs to be extremely cheap. To identify or compare files, use SHA-256.
Concepts worth knowing
Collisions and the birthday problem
SHA-256 has 2^256 possible outputs, more than there are atoms in the observable universe, so accidental collisions simply do not happen. The difficulty of *deliberately finding* one, however, is far lower than intuition suggests.
That is the birthday problem: just as 23 people in a room give better-than-even odds of a shared birthday, finding a collision in an n-bit hash takes roughly 2^(n/2) attempts rather than 2^n. For SHA-256 that is still 2^128 and safely out of reach, but for a 128-bit hash it drops to 2^64 — within range of a determined attacker. Always halve the bit length when judging a hash's strength.
Why HMAC beats hashing a concatenation
Simply prepending a secret — hash(secret + message) — is vulnerable to a length-extension attack. Merkle–Damgård hashes like SHA-256 expose enough internal state that an attacker who never learns the secret can still append data and produce a valid signature for the extended message.
HMAC blocks this by applying the key twice with two different pads: hash(key⊕opad + hash(key⊕ipad + message)). That is why webhook signatures and API authentication specify HMAC. Do not invent your own sha256(secret + body) scheme.
Compare signatures in constant time
Verifying a signature server-side with if (computed === received) leaks information through timing. Most string comparisons bail out at the first differing character, so a value that matches further along takes measurably longer.
An attacker can measure that difference repeatedly and recover the correct value one character at a time. Use a constant-time comparison instead — crypto.timingSafeEqual in Node, hmac.compare_digest in Python. The comparison feature in this tool is for reading with your eyes in a browser, so it does not apply here.