Why password hashing is not optional
Storing passwords in plaintext is the single most catastrophic mistake a developer can make. When a database is breached — and breaches are a question of when, not if — plaintext passwords give attackers immediate access to every user account. Hashing transforms each password into an irreversible fixed-length string, so even a stolen database reveals only hashes, not the original passwords. Among hashing algorithms, bcrypt is widely recommended because it is intentionally slow, making brute-force and dictionary attacks computationally expensive. The cost factor lets you dial up the work required as hardware gets faster.
This tool generates a bcrypt-format hash string (2bNN$salt+hash) using PBKDF2-SHA256 via the Web Crypto API. You enter a password, pick a cost factor from 4 to 31 (default 12), and copy the resulting hash. A fresh 16-byte salt is generated for every hash using `crypto.getRandomValues`. The output format matches bcrypt conventions, making it straightforward to verify against server-side bcrypt libraries. All computation runs locally in your browser.
How the hashing process works
The tool takes three inputs: your password, a cost factor, and a randomly generated 16-byte salt. The cost factor determines how many iterations of the key derivation function run — each increment doubles the computation time. The PBKDF2-SHA256 function repeatedly hashes the password with the salt for 2 to the power of the cost factor iterations. The final output is formatted as a bcrypt-compatible string: `$2b$` followed by the two-digit cost, the 22-character base64-encoded salt, and the 31-character base64-encoded hash. While this is not native bcrypt (which requires Blowfish and native code), the output format and security properties are designed to interoperate with standard bcrypt verification.
| Component | Format | Purpose |
|---|---|---|
| Algorithm prefix | 2b | Identifies the bcrypt format version |
| Cost factor | 04-31 (two digits) | Controls iteration count (2^N) |
| Salt | 22 base64 chars | Unique per-hash randomness |
| Hash | 31 base64 chars | Derived key output |
| Full string | 60 characters total | Copied to clipboard for use |
How to generate a bcrypt hash
Enter the password you want to hash
Pick a cost factor between 4 and 31 — 12 is the recommended default for most applications
Click Generate hash to run the derivation
Copy the full 60-character bcrypt-format string from the output field
How to verify your hash output
Paste the same password and generate a hash twice — the two outputs should differ because each run uses a fresh random salt. However, a bcrypt verification function should confirm that both hashes match the original password. You can also verify the format: every bcrypt hash starts with `$2b$` followed by a two-digit cost, a `$` separator, 22 salt characters, another `$` separator, and 31 hash characters, for a total of exactly 60 characters. Check that the cost in the output matches what you selected.
Common hashing mistakes
Using a very low cost factor (under 10) which makes the hash fast to compute and vulnerable to brute-force attacks on modern hardware
Setting the cost too high (above 14) for a web login endpoint, which causes unacceptable latency for users during the authentication request
Assuming this browser-based output is safe for production password storage — use a server-side bcrypt library for actual user authentication systems
Reusing the same salt across multiple passwords, which defeats the purpose of per-hash randomization
Browser versus server-side hashing
This tool uses PBKDF2-SHA256 formatted to look like bcrypt, which is practical for browser environments where native Blowfish (the algorithm real bcrypt uses) is unavailable. The security properties are strong — PBKDF2 with a high iteration count and a cryptographically random salt is a NIST-approved key derivation function. For production password storage, however, you should use a server-side bcrypt, argon2, or scrypt library that has been audited and battle-tested. The browser tool is best suited for prototyping, testing, and educational purposes rather than securing real user credentials.
Practical use cases
Developers prototyping authentication flows and testing hash verification logic locally
Security educators demonstrating the effect of cost factors on hashing time
Database administrators generating test hashes to seed development databases with realistic-looking user records
Penetration testers verifying that a target system correctly handles bcrypt comparison
Frequently asked questions
Q: Is this real bcrypt?
A: No — real bcrypt needs native code. This tool uses PBKDF2-SHA256 (Web Crypto) and formats the output in bcrypt's 2b format. Use a server-side library for production password storage.
Q: What's the cost factor?
A: Each increment doubles the work factor. 12 is a sensible default for production; 14+ starts to feel slow on commodity hardware.
Q: Where does the salt come from?
A: crypto.getRandomValues generates a fresh 16-byte salt for each hash. The salt is embedded in the output string.
Q: Can I verify passwords against this hash on my server?
A: Yes — if your server uses a bcrypt library that supports the 2b prefix, it should be able to verify passwords against hashes generated here, since the format is compatible.
Q: What happens if I set cost to 31?
A: Cost 31 means 2 to the 31st power (over 2 billion) iterations. This will take an extremely long time in a browser and is not practical for interactive use. It is included for completeness.
Generate your hash now
Create a bcrypt-format hash in seconds with the bcrypt Hash Generator. For related security tools, explore the Hash Generator, the HMAC Generator, or the SSH Key Generator.
