Hash Generator
Generate cryptographic digests of any text with every common SHA algorithm at the same time, plus a CRC32 checksum.
How it works
A hash maps input of any size onto a fixed-length digest. The same input always gives the same digest, a one-character change gives a completely different one, and the process cannot be reversed — which is what makes hashes useful for verifying that data has not changed.
All four SHA digests are computed with the browser's Web Crypto API, the same implementation your application will use. CRC32 is included separately: it is not cryptographic at all, just a fast checksum for spotting accidental corruption.
The formula
Digest length
SHA-1 = 160 bits, SHA-256 = 256, SHA-384 = 384, SHA-512 = 512
Avalanche
one bit changed in the input flips about half the output bits
Worked examples
| Scenario | Working | Result |
|---|---|---|
| “abc” with SHA-256 | Standard test vector | ba7816bf8f01cfea… |
| “abc” vs “abd” | One letter changed | Completely different digest |
| An empty string | Still hashes | e3b0c44298fc1c14… for SHA-256 |
When you'd use it
- Verifying a downloaded file matches its published checksum
- Generating a cache key from a request body
- Comparing two large values without storing them
- Producing a content fingerprint for deduplication
Common questions
Can I use SHA-256 to store passwords?
No. SHA is designed to be fast, which lets an attacker try billions of guesses per second. Password storage needs a deliberately slow algorithm — bcrypt, scrypt or Argon2.
Is SHA-1 still safe?
Not for anything security-related. Practical collisions were demonstrated in 2017, so it must not be used for signatures or certificates. It is included here only for checking against legacy systems.
Why is CRC32 listed alongside the SHA digests?
Because it answers a different question. CRC32 detects accidental corruption quickly but is trivial to forge, so it is right for checking a file transferred cleanly and wrong for anything involving an adversary.