Bcrypt Generator
Generate secure Bcrypt password hashes.
About Bcrypt Generator
bcrypt, published by Niels Provos and David Mazières in 1999, is a password hash built on the Blowfish key schedule. Its defining trick is that the expensive key-setup step is repeated a configurable number of times, so the algorithm can be made slower on purpose as hardware gets faster. Type a password above, choose a cost, and this page produces the same 60-character string your backend would store.
Why slow is the point
A general-purpose digest such as SHA-256 is designed to be fast, and commodity GPUs will compute billions of them per second — which is exactly the wrong property for a stolen password table. The cost factor here runs 4 to 15, and each increment doubles the work. Moving from 10 to 12 makes one login take four times longer, an amount of time a user will not notice, while multiplying an offline cracking run from days into weeks.
Everything travels in one string
The salt is not a separate column. It is generated fresh for every hash, base64-encoded into the middle of the output, and read back out at verification time. That self-describing layout is why a stored bcrypt hash remains verifiable after you raise the cost for new sign-ups: old records carry their own, lower cost, and you re-hash them opportunistically the next time each user logs in.
Practical cautions
The password box on this page is a plain text field, not a masked one, so what you type is visible to anyone looking at the screen or watching a recording. At cost 14 or 15 the hash takes a noticeable moment and the tab stops responding while it runs, because the underlying library is synchronous — that is the algorithm working, not a hang. The intended uses are seeding a development database, building a fixture, reproducing a login bug, or seeing for yourself what a work factor change costs.
When to reach for something else
bcrypt is tuned against CPU time only, so a well-funded attacker with custom hardware gains more against it than against a memory-hard design; for a greenfield system, Argon2id is the current recommendation. For file integrity or a content fingerprint you want the Hash Generator, not a password hash. To judge whether a password is worth protecting in the first place, try the Password Strength Checker.
Cost 4 To 15, On A Slider
The work factor is exposed directly rather than fixed. Each step up doubles the number of key-setup iterations, so cost 12 costs four times what cost 10 does — for you and for anyone attacking the hash.
Reads Like Your Database Column
Output is the familiar 60-character modular crypt string: $2b$, the two-digit cost, then a 22-character salt and a 31-character digest, ready to paste straight into a seed script or fixture.
The Password Stays In The Tab
bcryptjs is a pure-JavaScript implementation running on this page. No request is made when you press Generate, so the value never reaches a log, a proxy or a server.
Frequently Asked Questions
What do the parts of the hash mean?
A result such as $2b$10$WDr99h.TmEHl8zdvtsPWbOUeFUYelZHAiZZWZKdw7xYEvYLP4gGe6 is four fields separated by dollar signs. $2b$ names the algorithm revision, 10 is the cost, and the remaining 53 characters are a 22-character salt followed by the 31-character digest. Everything a verifier needs is inside that one string, which is why the column in your database only has to store 60 characters and never a separate salt.
Why do I get a different hash every time for the same password?
Because a fresh random salt is drawn on every click. Two hashes of the same password share only the seven-character $2b$nn$ prefix and differ from the eighth character onwards, and neither one is more correct than the other. This is what makes precomputed rainbow tables useless, and it is also why you must never compare hashes with a string equality check — pass the candidate password and the stored hash to your library's compare function and let it re-derive the digest using the salt it finds inside.
Which cost should I pick?
Choose the highest value your login endpoint can absorb at peak, then revisit it every couple of years as hardware improves; 10 to 12 is the usual range on server hardware. Do not calibrate from the timing you see here. This page uses a pure-JavaScript bcrypt, which is several times slower than the native builds used by Node, Python or PHP, so a cost that feels sluggish in this tab may be comfortably fast in production.
Why is my long passphrase not getting any stronger?
bcrypt only reads the first 72 bytes of the input and silently ignores everything after. That is bytes, not characters, so a passphrase of accented or CJK text hits the ceiling sooner than its length suggests. Anything beyond the cut-off contributes nothing, which means two different 100-character passphrases sharing a 72-byte prefix will validate against each other. Where long passphrases matter, pre-hash with SHA-256 before bcrypt, or use Argon2id instead.
Will these hashes work with my framework?
Yes, for anything that speaks the modular crypt format: Node's bcrypt and bcryptjs, PHP's password_verify, Python's bcrypt and passlib, Go's golang.org/x/crypto/bcrypt, and Spring Security's BCryptPasswordEncoder all accept the $2b$ prefix produced here. Some older stores hold $2a$ or $2y$ hashes; those remain verifiable and do not need regenerating, since the prefix records how the implementation handled a historical edge case rather than a different algorithm.
Can I check an existing hash against a password here?
No — this page only generates. Verification needs both the candidate password and the stored hash, and it belongs in your application code where a constant-time comparison and a rate limit are already in place. Nothing on this page reverses a hash either; bcrypt is one-way by design, and a tool claiming to decrypt one is really just guessing from a wordlist.