Hash Generator (MD5, SHA-256 & more)
Type once and get every digest at once — MD5, SHA-1, SHA-256, SHA-384, SHA-512, and CRC32 — computed in your browser.
Runs entirely in your browser. Nothing you paste here is uploaded, logged, or sent to analytics.
Which one should I use?
| Algorithm | Digest | Safe for security? | Notes |
|---|---|---|---|
| MD5 | 128 bits | No | Broken for collision resistance since 2004 (Wang et al.). Fine as a non-security checksum or cache key; never for signatures, certificates, or password storage. |
| SHA-1 | 160 bits | No | Collisions demonstrated in practice (SHAttered, 2017). Still used by Git object IDs, but deprecated for any security purpose. |
| SHA-256 | 256 bits | Yes | The general-purpose default. Part of the SHA-2 family, FIPS 180-4. |
| SHA-384 | 384 bits | Yes | SHA-512 truncated to 384 bits, with different initial values. |
| SHA-512 | 512 bits | Yes | Wider SHA-2 variant; faster than SHA-256 on 64-bit hardware. |
| CRC32 | 32 bits | No | An error-detection checksum, not a hash function. Trivially forgeable — use it to catch corruption, nothing else. |
Never hash a password with any of these
Every algorithm here is designed to be fast, which is exactly wrong for password storage. A modern GPU computes billions of SHA-256 digests per second, so a leaked table of SHA-256 password hashes is a leaked table of passwords.
Password storage needs a deliberately slow, memory-hard, per-user-salted function. Use
Argon2id where available, or bcrypt or
scrypt otherwise. Every mainstream language has one built in or a single
dependency away: PHP's password_hash(), Python's argon2-cffi,
Go's golang.org/x/crypto/bcrypt, Node's argon2.
Adding a salt to SHA-256 yourself does not fix this. Salting defeats precomputed rainbow tables; it does nothing about raw brute-force speed, which is the actual problem.
What these are good for
- File integrity — checking a download against a published checksum. Paste the published value into the compare field above and it will tell you which algorithm it is.
- Cache keys and deduplication — a content digest as a stable identifier. MD5 is fine here; you are not defending against an adversary.
- Change detection — cheaply telling whether a blob of content has changed since you last saw it. CRC32 is enough, and is what ZIP and PNG use internally.
- HMAC and signatures — but use SHA-256 or better, and use a real HMAC construction rather than concatenating a key with the message.
Why "broken" does not always mean "unusable"
MD5 and SHA-1 are broken for collision resistance: an attacker can construct two different inputs with the same digest. Git still uses SHA-1 for object IDs and Linux distributions still publish MD5 checksums, because in both cases the threat being defended against is accidental corruption, not a motivated forger.
The line is simple: if an attacker benefits from finding two inputs with the same digest, you need SHA-256 or better. If you only need to notice that bytes changed by accident, anything on this page works.
Where the computation happens
SHA-1, SHA-256, SHA-384, and SHA-512 come from your browser's built-in
crypto.subtle.digest(). MD5 and CRC32 have no WebCrypto equivalent, so both
are implemented here from their specifications (RFC 1321 and the ITU-T V.42 polynomial) and
verified in CI against the published test vectors — the full RFC 1321 suite for MD5 and the
standard CRC32("123456789") = 0xCBF43926 check value.
Nothing is transmitted. Unlike most "online hash generator" sites, the text you type here never reaches a server, which matters given how often people paste secrets into these tools.