What is bcrypt and why use it for passwords?

Bcrypt is an adaptive password-hashing function based on the Blowfish cipher, designed by Niels Provos and David Mazières in 1999. Unlike a plain SHA-256 of a password (which a GPU can guess at billions of attempts per second), bcrypt deliberately makes hashing slow via a cost factor — doubling the cost roughly doubles the time. The hash also includes a per-password 128-bit salt, so identical passwords produce different hashes and rainbow tables are useless. It is the default password hash in Ruby on Rails, Spring Security, Laravel, and most Node.js stacks.

What cost factor (rounds) should I pick?

OWASP 2026 recommends a minimum cost of 10 for bcrypt. Most production systems use 10-12. The cost factor is logarithmic — cost 12 takes 4× as long as cost 10. Use the benchmark badge in the tool to pick a value that takes ~250-1000 ms on the slowest device that will run your hashing (typically your production server, not your laptop). Costs above 12 can feel sluggish on mobile and may exhaust serverless function budgets, so test against your real environment.

What is the difference between $2a$, $2b$, and $2y$?

$2a$ was the original bcrypt prefix and is what older Crypt::Eksblowfish-style libraries emit. A 2011 wraparound bug in some C implementations led to $2x$ (broken) and $2y$ (PHP fix) prefixes; $2y$ is still common in PHP password_hash() output. $2b$ is the modern unambiguous prefix used by OpenBSD, bcryptjs, and most current libraries — it is byte-compatible with corrected $2a$ implementations. The bcryptjs library used here verifies all three formats interchangeably, so a $2y$ hash from PHP will verify correctly with the same password.

Is it safe to type my password into this page?

All bcrypt hashing and verification runs locally via the bcryptjs JavaScript library — your password is never uploaded, logged, or transmitted, and the network tab will confirm that. That said, the standing rule for any online crypto tool applies: never paste production passwords into a browser tool you do not control. Use throwaway test passwords when iterating; reserve real credentials for your own backend or a CLI you trust.

Why does bcrypt cap passwords at 72 bytes?

Bcrypt is built on the Blowfish key schedule, which only consumes the first 72 bytes (576 bits) of the password input. Anything beyond that is silently ignored, which means two long passwords sharing the same 72-byte prefix will collide. A common defense is to pre-hash with SHA-256 (yielding 32 bytes) before passing to bcrypt — though this opens the door to "shucking" attacks if the SHA-256 hash leaks separately. The tool warns when your input exceeds 72 bytes (counted as UTF-8, so emojis count as 4 bytes each).

Should I use bcrypt or argon2 / scrypt for new projects?

Argon2id (Password Hashing Competition winner, 2015) is the current OWASP-recommended choice for new systems — it is memory-hard, which makes GPU and ASIC attacks much more expensive than against bcrypt. Scrypt is also memory-hard and a reasonable choice. Bcrypt remains a solid pick because it has 25+ years of cryptanalysis, broad library support, and a well-understood threat model — there is no urgent reason to migrate an existing bcrypt deployment, but new greenfield projects should evaluate argon2id first.

Bcrypt Generator — Hash & Verify Passwords

Bcrypt Generator & Verifier

Hash and verify passwords with bcrypt — fully client-side, with cost-factor benchmarking.

Processed locally in your browser

Password

0 / 72 bytes (UTF-8)

Cost factor: 10

recommended

OWASP 2026 baseline for bcrypt password hashing.

Privacy: Bcrypt hashing and verification run entirely in your browser via the bcryptjs library. Your password is never uploaded, logged, or sent to any server. Still, never paste production passwords into an online tool. For random secrets, see the Password Generator; for unkeyed digests use Hash Generator.

Unlock the full toolkit

Batch processing, no ads, higher limits, and API access.

Go Premium

How to Use

1. Switch between Generate and Verify modes with the tabs at the top. 2. Generate: type a password, pick a cost factor (10 is the OWASP 2026 baseline), and press Generate — the bcrypt hash appears with a structure breakdown ($2b$ | rounds | salt | hash). 3. Verify: paste a bcrypt hash, type the candidate password, and press Verify — you get a green Match or a red No match instantly. 4. Use the cost-factor benchmark to pick a value that takes ~250-1000 ms on your hardware. For unkeyed digests use Hash Generator; for HMAC signatures use HMAC Generator; for random passwords use Password Generator.

Features

✓Generate bcrypt hashes with cost factor 4-15 ($2b$)
✓Verify a password against any $2a$ / $2b$ / $2y$ hash
✓Real-time benchmark — measure cost on your device before committing
✓Hash structure breakdown: version, rounds, salt, hash
✓OWASP 2026 cost-factor guidance built into the slider
✓Bcrypt library lazy-loaded to keep the page bundle small
✓Fully client-side — passwords never leave your browser
✓Show/hide password toggle and one-click copy of the hash

Frequently Asked Questions

What is bcrypt and why use it for passwords?: Bcrypt is an adaptive password-hashing function based on the Blowfish cipher, designed by Niels Provos and David Mazières in 1999. Unlike a plain SHA-256 of a password (which a GPU can guess at billions of attempts per second), bcrypt deliberately makes hashing slow via a cost factor — doubling the cost roughly doubles the time. The hash also includes a per-password 128-bit salt, so identical passwords produce different hashes and rainbow tables are useless. It is the default password hash in Ruby on Rails, Spring Security, Laravel, and most Node.js stacks.
What cost factor (rounds) should I pick?: OWASP 2026 recommends a minimum cost of 10 for bcrypt. Most production systems use 10-12. The cost factor is logarithmic — cost 12 takes 4× as long as cost 10. Use the benchmark badge in the tool to pick a value that takes ~250-1000 ms on the slowest device that will run your hashing (typically your production server, not your laptop). Costs above 12 can feel sluggish on mobile and may exhaust serverless function budgets, so test against your real environment.
What is the difference between $2a$, $2b$, and $2y$?: $2a$ was the original bcrypt prefix and is what older Crypt::Eksblowfish-style libraries emit. A 2011 wraparound bug in some C implementations led to $2x$ (broken) and $2y$ (PHP fix) prefixes; $2y$ is still common in PHP password_hash() output. $2b$ is the modern unambiguous prefix used by OpenBSD, bcryptjs, and most current libraries — it is byte-compatible with corrected $2a$ implementations. The bcryptjs library used here verifies all three formats interchangeably, so a $2y$ hash from PHP will verify correctly with the same password.
Is it safe to type my password into this page?: All bcrypt hashing and verification runs locally via the bcryptjs JavaScript library — your password is never uploaded, logged, or transmitted, and the network tab will confirm that. That said, the standing rule for any online crypto tool applies: never paste production passwords into a browser tool you do not control. Use throwaway test passwords when iterating; reserve real credentials for your own backend or a CLI you trust.
Why does bcrypt cap passwords at 72 bytes?: Bcrypt is built on the Blowfish key schedule, which only consumes the first 72 bytes (576 bits) of the password input. Anything beyond that is silently ignored, which means two long passwords sharing the same 72-byte prefix will collide. A common defense is to pre-hash with SHA-256 (yielding 32 bytes) before passing to bcrypt — though this opens the door to "shucking" attacks if the SHA-256 hash leaks separately. The tool warns when your input exceeds 72 bytes (counted as UTF-8, so emojis count as 4 bytes each).
Should I use bcrypt or argon2 / scrypt for new projects?: Argon2id (Password Hashing Competition winner, 2015) is the current OWASP-recommended choice for new systems — it is memory-hard, which makes GPU and ASIC attacks much more expensive than against bcrypt. Scrypt is also memory-hard and a reasonable choice. Bcrypt remains a solid pick because it has 25+ years of cryptanalysis, broad library support, and a well-understood threat model — there is no urgent reason to migrate an existing bcrypt deployment, but new greenfield projects should evaluate argon2id first.

Bcrypt Generator & Verifier

How to Use

Features

Frequently Asked Questions

Related Tools