Free Online Bcrypt Hash Generator & Checker
Generate strong salted bcrypt password hashes instantly, or verify a password against an existing hash. All processing runs locally in your browser.
Key Features
Salted Hashing
Each hash includes a unique salt, making rainbow table attacks infeasible. No two hashes of the same password are ever identical.
Adjustable Cost
Control the work factor from 4 to 15. Higher values make hashing slower and more resistant to brute-force attacks.
Hash Verification
Easily verify passwords against existing bcrypt hashes to confirm correctness without re-encrypting.
Privacy Protected
All hashing runs entirely in your browser via bcryptjs. No passwords or hashes are ever sent to any server.
Understanding Bcrypt for Password Storage
Bcrypt is the de facto standard for password hashing in modern web applications. It was designed by Niels Provos and David Mazières in 1999 as an adaptive cryptographic hash function based on the Blowfish cipher. Unlike fast hashing algorithms such as MD5 or SHA-256 — which can be computed billions of times per second on consumer GPU hardware — bcrypt is deliberately slow, making brute-force and dictionary attacks economically infeasible.
The cost factor (also called rounds or work factor) is the key parameter that controls bcrypt's computational difficulty. A cost factor of 10 means the algorithm performs 210 = 1,024 rounds of the key derivation function. Each increment of the cost factor doubles the time required to compute a single hash. As of 2026, a cost of 10 to 12 is recommended for most applications. Higher values offer more resistance to brute-force attacks but increase latency for legitimate users, especially during login. When choosing a cost factor, measure the hashing time on your production hardware — a good target is 250-500 milliseconds per hash, balancing security against user experience.
Every bcrypt hash incorporates a unique 16-byte salt generated from a cryptographically secure random source. The salt ensures that identical passwords produce completely different hash outputs, eliminating the effectiveness of precomputed rainbow tables. The salt is stored as part of the hash string (the first 22 characters after the cost identifier), so no separate salt storage is needed — the output is self-contained. A complete bcrypt hash follows the format $2b$10$[22-char-salt][31-char-hash], where $2b$ identifies the algorithm version.
In production, never store raw passwords in databases, log files, or error messages. Hash passwords immediately upon receipt using bcrypt with an appropriate cost factor, and verify passwords by hashing the candidate with the stored salt and comparing the result. Use a dedicated library (bcryptjs for Node.js, passlib for Python, or bcrypt for Java) rather than implementing the algorithm yourself. Consider future-proofing by storing the cost factor alongside each hash so you can gradually increase it as users authenticate over time — a technique known as "rehashing on login."