About this hash generator
A cryptographic hash function is a fixed-output, one-way fingerprint of arbitrary input. This page computes MD5 (legacy), SHA-1 (legacy), SHA-256, SHA-384, and SHA-512 entirely in your browser using the WebCrypto API (window.crypto.subtle.digest), which is the native, hardware-accelerated implementation shipped with Chrome, Firefox, Safari, and Edge. Nothing is uploaded; the input text is hashed locally and the digest is shown as a lowercase hex string of fixed length.
Three properties make a hash function useful. It is deterministic, so the same input always yields the same digest. It is collision-resistant, so finding two distinct inputs with the same digest is computationally infeasible. And it is one-way, so recovering the input from the digest requires brute force over the entire input space. Together these make hashes the backbone of git commit IDs, Bitcoin block headers, JWT signatures, TLS certificate fingerprints, content-addressable storage, and password verification (when paired with a salt and a cost factor).
How the WebCrypto implementation works
The generator processes text in three steps: encode to UTF-8 bytes, pass to crypto.subtle.digest, then format the returned ArrayBuffer as a hex string.
async function hash(algo, msg) {
const bytes = new TextEncoder().encode(msg); // UTF-8 encode
const buffer = await crypto.subtle.digest(algo, bytes);
return Array.from(new Uint8Array(buffer))
.map(b => b.toString(16).padStart(2, '0'))
.join('');
}
// hash('SHA-256', 'hello world') -> 'b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9'
The same digest will be produced by echo -n 'hello world' | shasum -a 256 on macOS or Linux, by Get-FileHash -Algorithm SHA256 in PowerShell, and by hashlib.sha256(b'hello world').hexdigest() in Python. Different output usually means one side added a trailing newline.
Worked example: verifying a download
The Linux kernel project publishes SHA-256 checksums alongside every release. To verify linux-6.8.tar.xz you would:
- Compute
sha256sum linux-6.8.tar.xzon your machine. - Compare to the published digest in
sha256sums.asc. - Optionally verify the PGP signature on the checksum file so an attacker cannot substitute both file and checksum.
A digest such as 5b6ae74b... 64 hex chars total is 256 bits. The chance of two unrelated files colliding by accident is roughly 1 in 2^128, which is below the noise floor of cosmic ray bit flips. If your computed digest does not match, redownload; if it still does not match, the published file was corrupted in transit or tampered with.
Hash algorithms compared
| Algorithm | Output size | Year | Security status | Use cases |
|---|---|---|---|---|
| MD5 | 128 bit (32 hex) | 1992 | Broken (collisions found 2004) | Checksums only. NEVER for passwords or security. |
| SHA-1 | 160 bit (40 hex) | 1995 | Broken (Google SHAttered 2017) | Git internal IDs. Being phased out. |
| SHA-256 | 256 bit (64 hex) | 2001 | Secure | Bitcoin, TLS certificates, signatures. |
| SHA-512 | 512 bit (128 hex) | 2001 | Secure | When you want larger digest. Faster than SHA-256 on 64-bit CPUs. |
| SHA-3 (Keccak) | Variable | 2015 (NIST) | Secure | Drop-in SHA-2 replacement; different construction. |
| BLAKE2 / BLAKE3 | Variable | 2012 / 2020 | Secure | Fastest secure hash. Used in WireGuard, Argon2. |
| bcrypt / scrypt / Argon2 | Variable | 1999 / 2009 / 2015 | Secure for passwords | Password storage ONLY (not general hashing). |
Common pitfalls
- Treating a hash as encryption. Hashing is one-way; encryption is reversible with a key. A site that promises to 'decrypt SHA-256' is running a rainbow-table lookup against common inputs (passwords, short strings) and failing on anything unique.
- Using fast hashes for password storage. SHA-256 of a password is wrong. Modern GPUs hash billions of SHA-256 inputs per second, so the entire space of plausible passwords falls in minutes. Use Argon2id, scrypt, or bcrypt with appropriate cost parameters (OWASP 2025 guidance: Argon2id, m=19456, t=2, p=1).
- Mismatched encodings. Hashing the string 'hello' as UTF-16 LE produces a different digest than UTF-8 (which is what WebCrypto encodes here). Always specify and document the encoding when sharing hashes.
- Trusting MD5 or SHA-1 in 2026. MD5 collisions are seconds on a laptop; SHA-1 collisions cost about USD 75,000 of compute (Google SHAttered, 2017) and are far cheaper today. Migrate every security-relevant use to SHA-256, SHA-3, or BLAKE3.
- Forgetting trailing newlines.
echo hello | shasumhashes 'hello\n' (6 bytes);echo -n hello | shasumhashes 'hello' (5 bytes). Different inputs, different digests, common confusion. - Length-extension attacks on SHA-2. SHA-256 and SHA-512 allow an attacker who knows
H(secret || message)to computeH(secret || message || padding || extra)without knowing the secret. Use HMAC, or use SHA-3 / BLAKE2 which are immune.
Related cryptography tools
Frequently asked questions
Is MD5 still safe for file integrity checks in 2026?
For accidental corruption (download verification against a hash the publisher signed elsewhere), MD5 still detects bit flips reliably and is fine. For any setting where an attacker could substitute a malicious file with a matching hash, MD5 is dead. Collisions can be produced on a laptop in seconds. Use SHA-256, SHA-3, or BLAKE3 for every integrity check that has a security boundary, and reserve MD5 for non-adversarial checksums like deduplicating local backup files.
Can the same input ever produce two different SHA-256 hashes?
Never. SHA-256 is fully deterministic. Identical byte sequences produce identical digests on every implementation. If two tools disagree, you have an encoding difference: a UTF-8 BOM at the start, CRLF versus LF line endings, a trailing newline, or text normalized to NFC versus NFD. Compare the raw bytes (hex dump) of both inputs and the difference will be visible. This is also why git, blockchains, and content-addressable stores work: the hash IS the identity.
Why does the same password hash differently each time?
Password hashing functions (bcrypt, scrypt, Argon2id) prepend a random per-password salt before hashing. The salt is stored inside the output string itself, so verifying re-derives the same salt and runs the hash again. This is intentional: two users who picked the same weak password get different stored hashes, defeating rainbow tables and making each password a separate attack target. A raw SHA-256 of a password has neither salt nor cost, which is why it is wrong for storage.
What is HMAC and how is it different from a plain hash?
HMAC (Hash-based Message Authentication Code, RFC 2104) wraps a regular hash function around a shared secret key in a specific double-hashing construction. HMAC-SHA256 means SHA-256 used inside the HMAC scheme. Anyone with the key can compute or verify the tag; anyone without the key can do neither. Plain SHA-256 proves a message was not corrupted; HMAC proves the sender knows the key. JWT signing, AWS request signing, and webhook signature verification all use HMAC, not raw hashes.
Which is the fastest secure hash function in 2026?
BLAKE3, designed by Aumasson, O'Connor, Neves, and Wilcox-O'Hearn (2020). It typically runs six to ten times faster than SHA-256 on modern x86 CPUs and parallelizes across cores for very large inputs. Adoption is growing inside Rust tooling, WireGuard, Mercurial and several blockchain projects. SHA-3 (Keccak) is slower than SHA-2 in software but resistant to length-extension attacks that affect SHA-2. For most web work, SHA-256 is still the safest default because it is implemented natively in WebCrypto, OpenSSL, and every TLS stack.
