Bcrypt Generator — Hash and Verify Passwords With Bcrypt

Hash a password with bcrypt at the cost you choose, check a password against a bcrypt hash, and see what each part of the hash means.

Generate a bcrypt hash

28 of 72 bytes (UTF-8).
Each step doubles the time. 10–12 is the usual range for login hashes.

Verify a password against a hash

Hash anatomy
Version$2b$2b — OpenBSD 2014 fix for passwords longer than 255 bytes. Current default in bcrypt (C/Python/Node).
Cost102^10 = 1,024 key-expansion rounds
SaltO.0JDwgDTALNNPsTWXP1YO22 chars = 128 random bits, bcrypt Base64
Hash2o9FuEFCZZMBsOKg910t7.RrUqVQsmW31 chars = 184 bits of the 192-bit output

Passwords are hashed and checked in your browser with bcryptjs. Nothing is sent, stored or logged. Still, avoid pasting a live production password into any web page. Browse all free tools.

Found a problem, or something that could be better? We read every message and we fix things quickly.

This bcrypt generator hashes a password with bcrypt at a cost factor from 4 to 15, verifies a password against an existing bcrypt hash, and breaks a hash into its version, cost, salt and digest. It is useful for seeding a test user, checking that a hash in your database matches a known password during a migration, or understanding what $2b$12$ actually means. Hashing runs in your browser with bcryptjs, a JavaScript implementation compatible with the bcrypt libraries used by Node.js, PHP, Python, Ruby and Go.

Bcrypt is slow on purpose, and each step up in cost doubles the time. The tool shows progress while it works and estimates how long other cost factors would take on your device, so you can see the trade-off before choosing one for a server. A word of caution that applies to every online tool: do not paste a live production password into a web page you do not control. Use this for test values and for understanding hashes.

How to use

  1. Enter a password and choose a cost factor; 10 to 12 is typical for login systems.
  2. Press Generate hash. A progress bar shows while it runs; at cost 14 or 15 that can take several seconds.
  3. Copy the 60-character hash. Generating again gives a different hash because the salt is random; both verify.
  4. To check a hash, paste it into the verify section with the candidate password and press Verify.
  5. Read the hash anatomy table to see which version and cost the hash uses.

Frequently asked questions

What cost factor should I use for bcrypt?

Choose the highest cost that keeps a single hash at a tolerable delay on your production server, typically 100 ms to 1 second. On current server hardware that is usually 10 to 12. OWASP's Password Storage Cheat Sheet sets a minimum work factor of 10. Measure on the real server rather than a laptop, and remember that a high cost also makes your login endpoint easier to overload with requests.

Why does the same password give a different bcrypt hash every time?

Each hash includes a new random 128-bit salt, stored in the hash itself (the 22 characters after the cost). That is intentional: two users with the same password get different hashes, and precomputed tables are useless. To check a password, bcrypt reads the salt and cost from the stored hash, re-hashes the candidate with them, and compares.

Can a bcrypt hash be decrypted?

No. Bcrypt is a one-way hash, not encryption. The only way to recover a password from a bcrypt hash is to guess candidates and hash each one, and the cost factor makes every guess expensive. That is its purpose: a weak password can still be guessed, but each attempt takes real CPU time instead of nanoseconds.

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

They mark revisions of the algorithm's implementation. $2a$ was the long-standing version; $2b$ was introduced by OpenBSD in 2014 to fix the handling of passwords over 255 bytes; $2y$ is PHP's marker for hashes produced after it fixed a sign-extension bug in 2011. For hashes created by current libraries, they verify the same way, and most libraries accept all three.

Is there a maximum password length for bcrypt?

Yes. Bcrypt uses only the first 72 bytes of the password and ignores the rest, and the count is in UTF-8 bytes, so a password of accented letters or emoji reaches the limit with fewer characters. This tool warns when you pass 72 bytes. If you need to accept longer passphrases, either cap their length or use Argon2id, which has no such limit.

Should I use bcrypt or Argon2?

For a new system, OWASP recommends Argon2id first, because it is memory-hard and therefore more expensive to attack with GPUs. Bcrypt remains a sound choice that is supported everywhere, and a system already using bcrypt with a cost of 10 or more is not in urgent need of change. What matters most is that you are using one of these slow, salted algorithms and not a plain SHA-256 or MD5.

Anatomy of a bcrypt hash

A bcrypt hash such as $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW is always 60 characters and carries everything needed to verify it:

• $2b$: the algorithm version.

• 12$: the cost factor. The key setup runs 2^12 = 4,096 times.

• R9h/cIPz0gi.URNNX3kh2O: 22 characters encoding the 128-bit random salt.

• PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW: 31 characters encoding 184 bits of the result.

The encoding uses bcrypt's own Base64 alphabet (./A–Z a–z 0–9), which is not the standard Base64 alphabet, so the parts cannot be decoded with an ordinary Base64 decoder.

Why fast hashes are wrong for passwords

General-purpose hashes like SHA-256 are designed to be fast, and a modern GPU computes billions of them per second. If a database of SHA-256 password hashes leaks, every common password and most short ones fall within hours. Adding a salt stops precomputed tables but does not slow the guessing down.

Bcrypt fixes that by making each hash deliberately expensive and tunable. At cost 12, one hash takes on the order of a quarter of a second on a typical server core, about a million times longer than a single SHA-256 on the same core, and bcrypt's memory access pattern also makes it run poorly on GPUs. As hardware gets faster, you raise the cost; existing hashes can be upgraded the next time each user logs in.

Hashing is only one layer. Rate-limit login attempts, check new passwords against lists of breached passwords as NIST SP 800-63B recommends, and offer two-factor authentication so that a guessed password alone is not enough.

Related free tools

  • Password Generator — Generate a strong random password, a memorable passphrase or a PIN. Runs entirely in your browser, nothing is sent or stored.
  • Hash Generator — Hash text or files with MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC32, verify a checksum, or compute an HMAC. Files never leave your device.
  • TOTP Generator — Turn a Base32 secret into live 2FA codes with a countdown, build an otpauth:// QR code for authenticator apps, or read an existing URI.
  • JWT Decoder — Decode a JWT's header and payload, read the expiry in plain language, verify HS, RS, PS and ES signatures, or sign a new token. Nothing leaves your browser.