bcrypt generator & verifier
Create a bcrypt hash, check a password against one, or take a hash apart. Runs in your browser.
bcrypt hashes you can create and check
Storing passwords safely means storing a salted, slow hash instead of the password itself, and bcrypt is still the most widely deployed choice in Java (Spring Security's BCryptPasswordEncoder), PHP, Ruby and Node applications. While developing you often need a hash by hand: seeding an admin user in a SQL script or a Liquibase changelog, writing a test fixture, or checking whether a stored hash matches a password someone swears they typed correctly.
Type a password and a cost factor to generate a bcrypt hash and see how long it took in your browser. Switch to Verify to check a password against an existing hash, or Inspect to take a hash apart into its version, cost, salt and digest. The tool warns when a password is longer than bcrypt's 72-byte limit (counted in bytes, so accented and emoji characters count more than one), and gives advice on the cost value based on the measured time.
Choosing a cost
- Aim for roughly a quarter second to a second per hash on the machine that verifies logins. Slower hardware or heavy login traffic argues for a lower cost; faster hardware allows a higher one.
- Cost 10 is the common default; 12 is a reasonable modern choice. Never go below 10 for new systems.
- Upgrade hashes gradually: when a user logs in successfully, rehash with the new cost and store it.
- For new designs consider Argon2id, which is also memory-hard.
Hashing runs in your browser with bcryptjs, a pure JavaScript implementation; nothing is uploaded. Still, do not paste real production passwords into any website. Use test data.
Frequently asked questions
What is bcrypt and why is it used for passwords?
bcrypt is a deliberately slow password hashing function with a built-in random salt and an adjustable cost. The slowness makes brute-force guessing expensive, and the salt makes identical passwords produce different hashes, which defeats rainbow tables.
What does the cost factor mean?
The cost is a power of two: a hash with cost 12 does 2^12 = 4096 rounds of key setup. Each increase of 1 doubles the time. Spring Security's BCryptPasswordEncoder defaults to 10; many teams use 12 or more today.
What do $2a$, $2b$ and $2y$ mean?
They identify the bcrypt version. $2b$ is the current one (a fix for a bug in 8-bit handling in some implementations), $2a$ and $2y$ are older or implementation-specific forms. Spring and other libraries verify all of them.
Why is there a 72-byte limit?
bcrypt only uses the first 72 bytes of the password. Longer passwords are silently truncated, so two different long passwords with the same first 72 bytes verify against the same hash. Pre-hash long inputs or choose Argon2 or scrypt for new systems.