SHA-256: One-Way Hashing That Actually Works
SHA-256 takes any input and produces a fixed 64-character hex string. Always the same length, whether you hash one byte or a 10 GB file. Always deterministic — same input, same output. And critically, irreversible — you can't work backwards from a hash to recover the input.
Hashing hello gives you:
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256 is the workhorse of modern cryptography. It's behind TLS certificates, Bitcoin's proof-of-work, Git commit IDs, Docker image layers, and virtually every integrity-checking system built in the last twenty years. It's part of the SHA-2 family, designed by the NSA, published by NIST in 2001, and it remains unbroken.
This SHA-256 generator is powered by the Web Crypto API. No signup, no install — just paste and go.
What's actually happening
SHA-256 is a cryptographic hash function. It takes arbitrary-length input, runs it through a series of bitwise operations, and produces a 256-bit (32-byte) output rendered as 64 hex characters.
Three properties make it useful:
One-way. Given a hash, there's no shortcut to find the input. The only option is brute force across 2²⁵⁶ possibilities — a number larger than the atoms in the observable universe.
Avalanche effect. Change one bit of input and roughly 50% of the output bits flip. Hash hello then hellp — the outputs share no visible pattern.
Collision resistant. It's computationally infeasible to find two different inputs that produce the same hash.
Using it
Type or paste text into the input. The hash generates instantly as you type. Hit Copy to grab it. Compare against a known hash to verify integrity.
When you'd actually reach for this
- You downloaded a binary release and want to verify it against the published checksum
- You need content-addressable storage keys — identical content maps to the same hash, deduplication is free
- You're building deterministic cache keys from request parameters:
sha256(JSON.stringify({ userId: 42, page: 3 })) - You're implementing webhook signature verification — Stripe signs payloads with HMAC-SHA-256 and you need to verify
- You want to checksum database migration files to detect if someone silently modified an already-applied migration
Why SHA-256 and not MD5 or SHA-1?
Because MD5 and SHA-1 are broken.
MD5 (128-bit) — practical collision attacks demonstrated in 2004. The Flame malware exploited MD5 collisions to forge Windows Update certificates. Still fine for non-security checksums (like checking if a file transfer was corrupted), but don't use it for anything security-related.
SHA-1 (160-bit) — deprecated since Google's 2017 SHAttered attack produced two PDFs with the same SHA-1 hash. Browsers stopped trusting SHA-1 certificates that year.
SHA-256 (256-bit) — no practical attacks exist. It's the minimum recommendation for any security-sensitive use.
| MD5 | SHA-1 | SHA-256 | |
|---|---|---|---|
| Output | 128-bit / 32 hex | 160-bit / 40 hex | 256-bit / 64 hex |
| Broken? | Yes (2004) | Yes (2017) | No |
| Use for security? | No | No | Yes |
If someone says "just use MD5, it's faster" — sure, it's faster. It's also broken. Speed is not the bottleneck in any realistic hashing scenario.
Troubleshooting
My hash doesn't match the expected value — check encoding. This tool uses UTF-8. If the other system used UTF-16 or Latin-1, the hashes will differ even for the same text. Also check for trailing newlines — hello and hello\n produce different hashes.
I hashed a file but the hash doesn't match the published checksum — you might be hashing the filename or file path instead of the file contents. On the command line, use shasum -a 256 file.bin or sha256sum file.bin.
Can I use SHA-256 for password hashing? — don't. SHA-256 is too fast. A GPU rig can compute billions of SHA-256 hashes per second. Use bcrypt, scrypt, or Argon2 instead — they're intentionally slow and memory-hard, which is exactly what you want for passwords.
Two different inputs gave me the same hash — no they didn't. Double-check for invisible characters, encoding differences, or copy-paste errors. No SHA-256 collision has ever been found.
What about SHA-512? — also SHA-2 family, 512-bit output, uses 64-bit operations so it's actually faster than SHA-256 on 64-bit CPUs. Both are secure. SHA-256 is more widely used and sufficient for everything.
What to do with the hash
If you're verifying integrity, compare it against the known-good hash. If they match, your data is intact.
If you're using it as a cache key or content address, store the hash as the key and the original data as the value. Same input will always produce the same key.
Don't store SHA-256 hashes of passwords. Use a proper password hashing function instead.