Bcrypt Generator
Generate and verify Bcrypt password hashes in your browser. Adjust the cost factor, inspect the output, and understand how secure password storage actually works.
Higher rounds increase cryptographic security exponentially but take significantly longer to compute.
Hashing vs. encryption — a critical distinction
This tool generates Bcrypt hashes — not encrypted ciphertext. The difference matters. Encryption is two-way: you can decrypt something if you have the key. Hashing is one-way: the original input cannot be mathematically recovered from the output. That's exactly what you want for password storage.
When a user logs in, you don't decrypt their stored hash — you hash what they typed and compare the two hashes. The plaintext password never needs to be stored or retrieved. Even the developers running the database can't see what any user's password is.
Bcrypt is the industry standard for this job. It's been in production since 1999, is supported natively in every major language, and remains unbroken. The tool here lets you generate, inspect, and verify hashes without sending your passwords anywhere.
Useful for anyone building or auditing auth systems
Backend Developers
Test your hashing library's output against known values, verify that your work factor is producing hashes in the expected time range, or debug a hash mismatch in a password reset flow.
Security Reviewers
Quickly inspect hashes from a database export to check the cost factor in use. A $2b$08$ prefix on every hash in a production database is a red flag worth raising.
Students & Learners
The best way to understand why Bcrypt is slow-by-design is to watch a cost-factor-14 hash take multiple seconds to compute. This tool makes that tangible without writing any code.
Generating and verifying a hash
Enter a password
Type or paste the password you want to hash. This runs entirely in your browser — nothing is transmitted. You can safely use real passwords here.
Choose a cost factor
The cost factor (also called rounds or work factor) controls how computationally expensive the hash is. For most web apps, 12 is a good starting point — it takes roughly 250ms on modern hardware. Try 8 and 14 to feel the difference.
Generate the hash
Click Generate. The tool derives the hash using your browser's CPU. Notice that the output changes every time you click — the embedded salt is re-randomized on each run.
Inspect the output
The resulting 60-character string starts with the algorithm version ($2b$), followed by the cost factor, then a Base64 encoding of the salt and ciphertext — all in one portable string.
Verify a hash
Paste an existing Bcrypt hash into the verify field, enter the password you think matches, and click Verify. The tool re-hashes using the embedded salt and tells you whether they match.
What every part of a Bcrypt hash means
$2b$
Algorithm version
$2b$ is the current Bcrypt standard. Older hashes may show $2a$ or $2y$ — functionally identical in most implementations, but $2b$ fixed a minor edge-case bug.
12
Cost factor
The work factor used to generate this hash. This number tells you it ran 2¹² = 4,096 internal iterations. To verify the password, the same 4,096 iterations must be repeated.
Remaining 53 chars
Salt + hash
The first 22 characters encode the random 128-bit salt. The final 31 characters are the actual password hash. Both live in the same string — no separate storage needed.
Choosing the right cost factor
The right cost factor is the one that takes around 250ms on your production server. Too fast and you've underprotected your users; too slow and login endpoints become a self-inflicted denial-of-service risk. Benchmark on your actual hardware.
Low / Legacy
8 – 10
- · ~5–30ms per hash
- · Fine for IoT or very old servers
- · Avoid in new production systems
Standard
11 – 12
- · ~100–300ms per hash
- · Right balance for most web apps
- · OWASP recommendation as of 2024
High Security
13 – 16
- · ~500ms – several seconds
- · For financial or medical systems
- · Requires rate limiting on login
The full lifecycle of a stored password
Modern authentication systems never store what you type. Here's what actually happens from registration to login:
Registration
- 1.User submits a password over HTTPS.
- 2.Server generates a random 128-bit salt.
- 3.Password + salt is fed into Bcrypt at the configured cost factor.
- 4.Only the 60-character hash is stored in the database.
- 5.The plaintext password is discarded immediately.
Login
- 1.User submits their password over HTTPS.
- 2.Server retrieves the stored hash from the database.
- 3.The salt is extracted from the first 29 characters of the stored hash.
- 4.The submitted password is hashed using that same salt and cost factor.
- 5.If the two hashes match byte-for-byte, access is granted.
Bcrypt vs SHA-256 vs Argon2
Not all hash functions are created equal. The wrong choice for password storage is one of the most common and costly security mistakes in web development.
| Feature | Bcrypt | SHA-256 | Argon2 |
|---|---|---|---|
| Designed for | Password storage | Checksums & signing | Password storage |
| Speed | Intentionally slow | Extremely fast | Tunable & slow |
| Salt handling | Built-in & automatic | Manual | Built-in & automatic |
| GPU resistance | Strong | Very weak | Very strong |
| Memory hardness | Moderate | None | High (configurable) |
| Adoption & support | Universal | Universal | Growing |
| Best for | Production passwords | File integrity, HMAC | New high-security systems |
What to watch out for
The 72-byte truncation limit
Bcrypt silently truncates any password exceeding 72 bytes — a constraint inherited from the Blowfish cipher. Most users never hit this limit, but if your application supports long passphrases, pre-hash with SHA-256 before passing to Bcrypt. This converts arbitrarily long input into a fixed 32 bytes, well within Bcrypt's limit and with no information loss.
High cost factors as a DoS vector
A cost factor of 16 can take several seconds of CPU per hash. An attacker who knows this can flood your login endpoint with requests, pinning your CPU at 100% without needing any valid credentials. The mitigation is straightforward: rate-limit login attempts by IP and account, and add CAPTCHA after repeated failures. Don't let the cost factor be the only line of defense.
Bcrypt is not for data encryption
A hash is not a cipher. If you need to store sensitive data that you'll need to read back later (API keys, PII, medical records), Bcrypt is the wrong tool. Use AES-256 encryption for that, and Bcrypt for passwords. They solve different problems.
Old hashes don't automatically upgrade
If you raise your cost factor from 10 to 12, existing stored hashes stay at cost factor 10 until users next log in. A common pattern is to silently re-hash on successful login when the stored hash's cost factor is below your current minimum. This way the database gradually migrates without any user friction.
Password security errors that keep appearing in breach reports
✗ Storing passwords in plaintext
The single most catastrophic mistake. A single database breach exposes every user instantly.
✗ Using MD5 or SHA-1 for passwords
Both are fast by design. A modern GPU can compute 60 billion MD5 hashes per second.
✗ Using a static, hard-coded salt
Defeats the entire purpose of salting. If the salt is the same, a rainbow table can be built for it.
✗ Setting cost factor below 10
On 2026 hardware, cost factor 8 hashes take under 10ms — fast enough to crack millions per day.
✗ No rate limiting on login endpoints
Even strong hashing can be brute-forced eventually if there's no lockout or throttling.
✗ Logging plaintext passwords accidentally
A surprisingly common bug: request body logging that captures the password field before hashing.
✗ Not re-hashing on cost factor changes
Raising the cost factor in config has no effect on existing hashes unless you re-hash on login.
✗ Skipping multi-factor authentication
Even a perfect hash is a single factor. MFA means a breached database doesn't equal breached accounts.
Why Bcrypt is still the default in 2026
Bcrypt was designed by Niels Provos and David Mazières in 1999 — before most current developers started their careers. It's been deployed in production systems for a quarter century without a fundamental break. That kind of track record is genuinely rare in cryptography.
Argon2, the winner of the 2015 Password Hashing Competition, has better theoretical properties: it's memory-hard, making it more resistant to specialized ASIC attacks. For new projects, it's a legitimate choice. But Bcrypt is available out of the box in every major framework — Rails, Django, Laravel, Express, Spring — with no additional dependencies. When the alternative requires a third-party library and careful configuration, many teams correctly stick with the battle-tested option.
The practical guidance from NIST and OWASP as of 2024 is to use Bcrypt at cost factor 10 or above, or Argon2id with appropriate memory and time parameters. Both are sound choices. Neither MD5 nor SHA-256 appear on any recommended list for password storage.
Common questions
Why does Bcrypt produce a different hash every time, even for the same password?
Each hash operation generates a fresh random 128-bit salt and embeds it directly in the output string. So even if ten users all choose 'hunter2', the database stores ten completely different-looking hashes. This defeats rainbow table attacks outright — a precomputed table of common hashes is worthless when every hash is unique.
Can I decrypt a Bcrypt hash back to the original password?
No, and that's the point. Bcrypt is a one-way function, not an encryption cipher. There's no mathematical inverse. To check whether a login attempt is correct, you run the submitted password through Bcrypt using the same salt (extracted from the stored hash) and see if the output matches. The plaintext is never stored or recovered.
What cost factor should I use in production?
The usual target is a hash time of around 250ms on your production hardware. On modern servers, that's typically cost factor 12. Too low (below 10) and the hash is cracked quickly if your database leaks; too high (above 14) and your login endpoint becomes a denial-of-service vector. Benchmark on your actual hardware and adjust accordingly.
What does the $2b$ prefix mean in the hash output?
The prefix encodes metadata about the hash itself. $2b$ identifies the Bcrypt algorithm version (the current standard). The number after it — like $12$ — is the cost factor. The remaining characters are Base64-encoded salt and ciphertext, all in one portable string. This self-contained format means you never need to store the salt separately.
What's the 72-byte password limit, and should I worry about it?
Bcrypt silently truncates input at 72 bytes due to a constraint in the underlying Blowfish cipher. In practice, very few real users set passwords longer than 72 characters. If you need to support passphrases beyond that length, pre-hash with SHA-256 before passing to Bcrypt — this converts arbitrarily long input into a fixed-size byte array that Bcrypt handles without truncation.
Why is Bcrypt more secure than SHA-256 for passwords?
SHA-256 was designed to be fast — it's used for checksums, file integrity, and digital signatures, where speed matters. A GPU can compute billions of SHA-256 hashes per second, making brute-force attacks cheap. Bcrypt was deliberately engineered to be slow and to resist GPU parallelization due to its memory-access patterns. Slowness is a feature, not a bug, when it comes to password storage.
Is Bcrypt still relevant now that Argon2 exists?
Yes. Argon2 won the Password Hashing Competition in 2015 and has better theoretical properties (especially memory hardness), but Bcrypt has a 25-year track record, is supported natively in virtually every language and framework, and remains unbroken in practice. For new greenfield projects, Argon2 is a fine choice. For existing systems running Bcrypt at a reasonable cost factor, migration is low priority.
Privacy note. This tool runs entirely client-side using a JavaScript implementation of Bcrypt. Your passwords are processed on your device's CPU only and are never sent to Kodivio's servers or logged anywhere. You can verify this in your browser's Network tab — there are no outbound requests when you click Generate.