Compute MD5, SHA-1, SHA-256, SHA-512 digests
A cryptographic hash function turns any input into a fixed-length fingerprint. Hashes are used to verify file integrity, derive cache keys, deduplicate data, and (with proper salting) store passwords. Different algorithms produce different lengths and have different security properties.
This tool computes MD5, SHA-1, SHA-256, and SHA-512 of any text input simultaneously. SHA family uses the browser's native SubtleCrypto; MD5 uses a JavaScript implementation. Everything runs locally — your input is never uploaded.
helloMD5: 5d41402abc4b2a76b9719d911017c592
SHA-1: aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-512: 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043SHA-256 by default — fast, well-supported, no known practical collisions. SHA-512 if you need a wider digest (e.g., for HMAC keys). Avoid MD5 and SHA-1 for any new system: both have practical collision attacks. They're still fine for non-security uses like file change detection or cache keys.
Plenty of legacy systems and protocols still use them — Git uses SHA-1 for commit IDs, and old APIs require MD5 checksums. The tool offers them so you can interop with those systems, not as a security recommendation.
No. Hashing is one-way: you can't recover the input from the hash. Encryption is two-way: with the key you decrypt back to the original. Use hashes for verification, not for hiding data — the input is gone once hashed.
Not in this tool — it's text-only. To hash a file, use a CLI: shasum -a 256 file (macOS/Linux) or certutil -hashfile file SHA256 (Windows). For very large files, streaming hash is far more efficient than loading the whole file into a browser.
No. Plain SHA-256 is far too fast for password storage — attackers can brute-force billions per second on a GPU. For passwords, use a password-specific KDF like bcrypt, scrypt, or Argon2 (server-side only).