Bcrypt Password Hasher — Hash, Verify & Compare Algorithms
Hash passwords with bcrypt and an adjustable cost factor, verify existing bcrypt hashes, and compare bcrypt against SHA-256, MD5, and Argon2 — all processed locally in your browser via bcryptjs. Your password is never sent to any server.
Estimated hash times by cost factor
Enter the original password and the bcrypt hash to verify they match. Verification timing shows why bcrypt is secure.
Comparison of password hashing approaches. Speed is a weakness for password storage — you want slow.
| Algorithm | Speed | Automatic Salt | Work Factor | Password Safe? |
|---|---|---|---|---|
| bcrypt | ~200ms / hash | Yes | Adjustable | Yes |
| Argon2 | Configurable | Yes | Adjustable | Best choice |
| scrypt | Configurable | Manual | Adjustable | Yes |
| SHA-256 | Billions/sec (GPU) | No | Fixed | No |
| SHA-512 | Billions/sec (GPU) | No | Fixed | No |
| MD5 | Tens of billions/sec | No | Fixed | Never |
Speed figures for SHA-256/MD5 are for raw hashing on modern GPUs. Bcrypt times are per-hash on a server CPU at cost=10.
How to Use the Bcrypt Password Hasher
- On the Hash Password tab, enter the password you want to hash.
- Adjust the cost factor slider — higher values are slower but more resistant to brute-force attacks. Cost 10 is the OWASP minimum; cost 12 is a practical production target.
- Click Generate Hash and wait for bcrypt to compute — the delay is intentional and demonstrates bcrypt's work factor.
- Copy the resulting hash string (starting with
$2a$) for storage in your database. - Switch to Verify Password, paste the hash and enter a password to confirm they match — the timing shows why bcrypt is slow by design.
- Open Algorithm Comparison to see a side-by-side table of bcrypt, Argon2, scrypt, SHA-256, SHA-512, and MD5 for password suitability.
Key Features
- Adjustable cost factor (4–12): Tune the work factor to balance security and performance for your specific hardware.
- Real-time cost timing chart: Visual bar chart shows estimated hash time per cost factor to guide your production configuration.
- Password verification: Verify any bcrypt hash against a plaintext password and see the exact verification time in milliseconds.
- Algorithm comparison table: See bcrypt, Argon2, scrypt, SHA-256, SHA-512, and MD5 rated on speed, automatic salting, work factor, and password safety.
- Show/hide password toggle: Reveal or mask the password input for convenience and safety.
- 100% client-side via bcryptjs: Your password is processed locally in the browser and never transmitted to any server.
Use Cases
Hash Passwords for Database Storage
When building authentication systems, passwords must never be stored in plain text or with a reversible algorithm. Use this tool to generate a bcrypt hash with an appropriate cost factor, then store the full hash string (including the embedded salt and cost factor) in your database. Your server-side code uses the same hash string to verify future login attempts.
Choosing the Right bcrypt Cost Factor
The optimal cost factor depends on your server hardware. OWASP recommends targeting a hash time of approximately 1 second on your production hardware. Use this tool's timing chart to see estimated times at each cost factor, then test on your actual server — cost 10 is the minimum, and cost 12 or higher is appropriate for modern hardware.
Verifying bcrypt Hashes During Development
When debugging authentication issues or testing your login implementation, paste the bcrypt hash from your database and enter the test password to confirm they match without needing to write backend code. The verification timing display helps confirm that the cost factor is working as expected.
Understanding Why SHA-256 Is Wrong for Passwords
The Algorithm Comparison tab makes the key difference visible: SHA-256 hashes at billions of operations per second on a GPU, while bcrypt at cost 10 takes ~200ms even on fast hardware. This tool lets you experience that difference directly and understand why a fast hash function is a security liability for password storage.
Teaching Password Security Concepts
The combination of adjustable cost factor, real-time timing, and algorithm comparison makes this tool useful for teaching password security. Students can directly observe how doubling the cost factor doubles the hash time, why automatic salting prevents rainbow table attacks, and which algorithms OWASP recommends for new applications.
FAQ's
OWASP recommends a minimum cost factor of 10. On modern hardware, cost 12 — targeting approximately 800ms per hash — is a good production choice. The right answer depends on your hardware: benchmark on your actual server and aim for the highest cost factor that keeps login response time under 1 second for users.
Bcrypt hashes cannot be reversed — there is no mathematical inverse. However, weak passwords can be found by brute-force: an attacker tries many candidate passwords and checks each against the stored hash. Bcrypt's slowness makes this impractical for complex, unique passwords. Bcrypt alone does not compensate for a weak password.
SHA-256 is designed to be extremely fast — modern GPUs can compute over 10 billion SHA-256 hashes per second. A bcrypt hash at cost 10 takes roughly 200ms even on fast hardware. An attacker who steals a database can make billions of guesses per second against SHA-256 hashes, but only a few per second against bcrypt hashes at the same cost.
Every bcrypt hash includes a unique 22-character random salt embedded directly in the hash string. This means two users with the same password produce completely different hashes. It also makes precomputed rainbow table attacks completely ineffective — each brute-force attempt must start from scratch for every individual hash.
Argon2id is the winner of the 2015 Password Hashing Competition and is now OWASP's recommended first choice for new applications. It is resistant to both GPU and side-channel attacks. bcrypt remains a solid, battle-tested choice with excellent library support across all major languages. If your platform supports Argon2id, prefer it; otherwise bcrypt is entirely acceptable.
Yes — bcryptjs is a pure JavaScript implementation of bcrypt that produces hashes fully compatible with the original C implementation (used by Python's bcrypt, PHP's password_hash, Node.js's bcrypt). It is slightly slower in the browser than native implementations, which is actually helpful for this demo. In production, always use a server-side native implementation.
A bcrypt hash looks like: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. The components are: $2a$ (algorithm version), 10 (cost factor), 22 Base64 characters of salt, then 31 Base64 characters of the hash. The entire 60-character string is what you store in your database.
No. All bcrypt computation runs locally in your browser using the bcryptjs library. Your password is never transmitted to any server, never logged, and is discarded when you close the tab. That said, for best security practice, avoid using real production passwords in any browser-based tool.