Hash Generator — SHA-1, SHA-256, SHA-384, SHA-512
Type any text below and instantly see its SHA-1, SHA-256, SHA-384 and SHA-512 hash. All four are computed in your browser using the native Web Crypto API. Your input never leaves your machine.
Type any text below and instantly see its SHA-1, SHA-256, SHA-384 and SHA-512 hash. All four are computed in your browser using the native Web Crypto API. Your input never leaves your machine.
A cryptographic hash function takes any input and produces a fixed-length output (32, 64 or 128 hex characters depending on the algorithm). Two key properties make it useful: identical inputs always produce identical outputs, and a tiny change in the input completely changes the output. Reversing a hash back to the input is computationally infeasible.
Hashes are everywhere: verifying that a downloaded file matches the publisher's checksum, indexing content in version-control systems like Git, deriving cache keys, signing JWT tokens, and storing passwords (with extra salt and slow-by-design functions like bcrypt or argon2).
No. Hashes are computed locally with the browser's Web Crypto API. Nothing leaves your machine — safe to use even with sensitive payloads.
The Web Crypto API does not implement MD5 because it is broken and should not be used in security contexts. If you need MD5 only for a non-security use case (e.g., legacy system compatibility), use a dedicated tool — adding it via WebAssembly is on the roadmap.
Currently the tool accepts only text input. File hashing via drag-and-drop is on the roadmap. As a workaround, paste the file contents (e.g., a small JSON or config file) into the input area.
Yes. The SHA-2 family (SHA-256, SHA-384, SHA-512) has no known practical collisions and remains the default recommendation for general-purpose cryptographic hashing. SHA-3 is also available in the Web Crypto API of some browsers but is not yet widespread. Avoid MD5 and SHA-1 for any security-sensitive use — both are considered broken.
Hashing is one-way: given the output, you cannot recover the input. Encryption is two-way: given the right key, you can decrypt back to the original data. Use hashing for fingerprints (file integrity, password storage with bcrypt/argon2, deduplication, content-addressed caching). Use encryption (AES, ChaCha20) when you need to read the data back later.
Real-world situations where a quick hash is exactly what you need.
Paste the same content you downloaded and compare the SHA-256 against the publisher's checksum. Mismatch means the file was tampered with or corrupted.
Hash the request payload to derive a stable cache key. Identical inputs produce the same key, so cache hits work across machines and deploys.
Quickly fingerprint each entry by SHA-256 and compare hashes. Two identical values always map to the same hash, so finding duplicates is O(n).
Test signature verification on the receiving end by hashing the body + secret here, then comparing to the X-Signature header your service emits.
Habits that make hashing safer and faster.
It covers 99% of use cases — file checksums, content-addressed caching, signing. Reach for SHA-512 only when an existing protocol mandates it.
Both are broken for security. They are still fine for non-adversarial integrity checks (cache keys, dedup) but not for anything an attacker could exploit.
When storing passwords or API keys, hash them with a slow function like argon2 or bcrypt. A hash you can't reverse is far safer than encryption you might leak the key for.
Change one bit in the input and the output changes completely. That property makes hashes great for spotting any tampering, however small.