What hashing is — and why it's different from encryption
Hashing is one-way: you can turn any input into a fixed-length digest, but you can't reverse the process. Encryption is two-way: you encrypt with a key and decrypt with a key. Hashing has no key — there is nothing to reverse with.
The practical consequence: if you hash a password and store the hash, you verify future logins by hashing the entered password and comparing the hashes. You never store the original password and never need it again. This is how secure authentication works. (Note: for passwords specifically, use bcrypt or Argon2 rather than SHA-256 — see the limitations section.)
Which algorithm to use and when
| Algorithm | Output length | Good for | Avoid for |
|---|---|---|---|
| MD5 | 128 bits (32 hex) | File integrity checksums (non-security) | Passwords, signatures, anything security-critical |
| SHA-1 | 160 bits (40 hex) | Legacy checksums, Git commit IDs | New security applications (collision attacks exist) |
| SHA-256 | 256 bits (64 hex) | File integrity, API request signing, token generation | Passwords (no work factor — use bcrypt) |
| SHA-512 | 512 bits (128 hex) | When extra collision resistance is needed | Passwords (still too fast to brute-force) |
The tool uses the Web Crypto API's crypto.subtle.digest() — the browser's native, hardware-accelerated hash implementation. All processing is client-side; your input never leaves your device.
When NOT to use SHA-256 for passwords
SHA-256 is very fast — modern GPUs can compute billions of SHA-256 hashes per second. For file integrity checks, this is fine. For passwords, it means an attacker with a GPU cluster can brute-force a SHA-256 password hash database in hours or days.
Password hashing functions like bcrypt, scrypt, and Argon2 are intentionally slow — they have a configurable work factor that makes each hash computation take 100ms or more. The same GPU that can compute billions of SHA-256 hashes per second can only compute thousands of bcrypt hashes per second. Use our Bcrypt tool for password hashing.
How to verify a file checksum with SHA-256
Software publishers post expected SHA-256 checksums next to download links. After downloading, hash the file here and compare — if the hashes match, the file is intact and unmodified. If they differ, the file is corrupted or tampered. Here's where to find the published checksum for common downloads:
| Software / source | Hash algorithm used | Where to find the expected hash |
|---|---|---|
| Ubuntu ISO | SHA-256 | SHA256SUMS file on the download page |
| Node.js release | SHA-256 | SHASUMS256.txt file on nodejs.org/dist |
| Python release | MD5 + SHA-256 | Table on python.org/downloads |
| Windows ISO (Microsoft) | SHA-256 | Listed on the official ISO download page |
| macOS software (Homebrew) | SHA-256 | Formula file in homebrew-core repo |
| GitHub release asset | SHA-256 | checksums.txt attached to the release page |
| Docker image digest | SHA-256 | docker inspect or Docker Hub → Tags tab |
You can also verify from the terminal: sha256sum filename on Linux/Mac or Get-FileHash filename -Algorithm SHA256 in PowerShell. This browser tool is faster for one-off checks without opening a terminal.