bcrypt hash generator
Enter a password, choose a cost factor, and generate a proper bcrypt hash suitable for storing in a real user database.
What bcrypt is and why it exists
bcrypt is a password-hashing function designed in 1999, built specifically to be slow and to stay slow even as computer hardware gets faster. It does this through a tunable "cost factor" (also called salt rounds): each increment of the cost factor doubles the computational work required to produce a single hash. A cost of 10 might take a few dozen milliseconds on typical hardware; a cost of 14 takes noticeably longer. That deliberate slowness is a feature — it's what makes brute-forcing a stolen bcrypt hash database orders of magnitude more expensive than brute-forcing a database of raw SHA-256 hashes.
bcrypt also generates and embeds a random salt automatically. You never manage the salt yourself — it's baked into the output string, which is why hashing the same password twice produces two different-looking hashes and why our bcrypt with salt explainer exists to clear up a common point of confusion.
Reading a bcrypt hash
A typical bcrypt output looks like this:
$2b$10$N9qo8uLOickgx2ZMRZoMy.MrqjcOA1zLBOOSnQ9wRlqjqQF3M3S6a
$2b$— the algorithm identifier/version.10$— the cost factor used (210 rounds).- The next 22 characters — the base64-encoded salt.
- The remaining 31 characters — the actual hash output.
Because the cost factor and salt travel with the hash, verifying a password later doesn't require you to store either separately — the verification function reads them straight out of the stored string.
What cost factor should you use?
| Cost factor | Approx. time per hash* | Typical use |
|---|---|---|
| 8–9 | < 50 ms | Legacy defaults, mobile-constrained hardware |
| 10–12 | ~60–250 ms | Current recommended range for most web applications |
| 13–14 | ~0.5–1 s | High-security applications where slower logins are acceptable |
*Actual timing depends heavily on server hardware — always benchmark on your own infrastructure.
Using this generator
Type a password, pick a cost factor from the dropdown, and click Generate. bcrypt is intentionally CPU-intensive, so higher cost factors will take a visibly longer moment to compute — that pause is bcrypt working as designed, not a bug.
Verifying a bcrypt hash
Generating a hash is only half the workflow. To confirm a plaintext password matches a previously stored hash — exactly what a login form needs to do — use our dedicated bcrypt generator and verifier page, which includes both tools together.
Frequently asked questions
Does bcrypt need a separate salt?
No. bcrypt generates a cryptographically random salt automatically and stores it inside the output hash string, so you never manage a salt column yourself.
What cost factor should I use in production?
Most current guidance recommends 10–12 for typical web applications, adjusted upward if your server hardware can absorb the extra CPU time without hurting login latency too much.
Is bcrypt still considered secure in 2026?
Yes, bcrypt remains a widely trusted, well-audited password hashing algorithm. Argon2 is a newer alternative with some additional memory-hardness properties, but bcrypt is still considered a safe, industry-standard choice.
Why does generating a hash take longer than MD5 or SHA-256?
That delay is intentional. bcrypt is built to be slow so that brute-forcing many password guesses against a stolen hash is expensive — the opposite design goal of a fast general-purpose hash.