Bcrypt Hash Generator
SecurityHash passwords with bcrypt and verify bcrypt hashes directly in your browser. Choose work factor from 4 to 16 to balance security and performance.
All hashing happens entirely in your browser — passwords never leave your device.
recommended · ~200 ms
About Bcrypt Hash Generator
The Bcrypt Generator hashes passwords using the bcrypt adaptive hashing algorithm and lets you verify whether a plaintext password matches an existing hash — all without sending data to a server. Bcrypt is specifically designed to be slow and computationally expensive, making brute-force and rainbow-table attacks impractical. Adjust the work factor (also called cost or rounds) from 4 to 16: each increment doubles the computation time, letting you tune the trade-off between security and response time as hardware improves. The tool runs a pure-JavaScript bcrypt implementation in a Web Worker so the UI remains responsive during expensive hash computations.
Features
- ✓Hashes passwords using the bcrypt/blowfish algorithm with a cryptographically random salt
- ✓Adjustable work factor from 4 (fast, for development/testing) to 16 (very slow, maximum security)
- ✓Verify mode: checks a plaintext password against an existing $2a$, $2b$, or $2y$ hash
- ✓Shows the generated salt separately for inspection
- ✓Runs in a Web Worker to avoid blocking the UI during expensive computations
- ✓Displays elapsed time for each hash so you can tune the cost factor for your server
- ✓One-click copy of the full hash string including version, cost, and salt prefix
- ✓Accepts hashes prefixed with $2a$, $2b$, and $2y$ for maximum compatibility
- ✓100 % client-side — passwords are never transmitted or stored
Common Use Cases
- Hashing passwords before storing them in a user database during application development
- Verifying that a stored bcrypt hash corresponds to a known password during testing
- Choosing the right work factor for a production server by measuring hash latency
- Creating test fixtures with known bcrypt hashes for unit or integration tests
- Generating .htpasswd entries with bcrypt hashing for Apache or Nginx basic auth
- Demonstrating adaptive password hashing in security workshops
- Comparing bcrypt output against implementation-specific hashes for interoperability testing
Frequently Asked Questions
QWhy should I use bcrypt instead of SHA-256 or MD5 for passwords?
SHA-256, MD5, and other general-purpose hash functions are designed to be fast, which makes them dangerous for password storage — modern GPUs can test billions of SHA-256 hashes per second. Bcrypt is intentionally slow and includes a built-in salt, making precomputed rainbow-table attacks impossible and brute-force attacks orders of magnitude more expensive.
QWhat work factor should I use in production?
OWASP recommends a work factor that causes bcrypt to take at least 100 ms on your production hardware, which typically corresponds to a cost of 10–12 on modern servers. Use the elapsed-time display in this tool to find the right value. If hardware improves, re-hash stored passwords to a higher cost factor at the next login.
QWhat is the difference between $2a$, $2b$, and $2y$ hash prefixes?
$2a$ is the original bcrypt prefix, later found to have an ambiguity bug with 8-bit characters. $2b$ fixes that bug and is the standard prefix used by OpenBSD and most modern libraries. $2y$ is used by PHP's crypt() and is functionally identical to $2b$. This tool outputs $2b$ hashes and can verify all three variants.
QCan bcrypt be reversed or cracked?
Bcrypt cannot be reversed mathematically — it is a one-way function. However, it can be brute-forced offline if a hash is leaked. The high cost factor is the primary defence: a work factor of 12 makes each guess take ~300 ms, limiting an attacker to ~3 guesses per second per CPU core. Use strong passwords and a high cost factor to make cracking infeasible.
QDoes bcrypt have a maximum password length?
Yes. The classic bcrypt algorithm passes the password through Blowfish key setup, which only processes the first 72 bytes of the password. Passwords longer than 72 bytes will be silently truncated. If you need to hash longer passwords, consider pre-hashing the password with SHA-256 (base64-encoded) before passing it to bcrypt — a common pattern in libraries like bcrypt.js.