What bcrypt cost should I use?

Each +1 doubles the work. OWASP recommends at least 10, and 10–12 is common; a practical target is roughly 100–300 ms per hash on your server, and you can get a feel for the timing here (browsers and servers differ). Note that bcrypt only uses the first 72 bytes of a password — anything after that doesn’t change the hash, and the tool warns you about it.

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

The algorithm is the same; the prefixes mark historical bug fixes. $2a$ is the early version, $2y$ is what PHP adopted after fixing a flaw in its implementation, and $2b$ is OpenBSD’s marker after fixing a length overflow with very long passwords. For passwords up to 72 bytes all three produce the same result and generally verify interchangeably. $2b$ is recommended for new systems (PHP outputs $2y$).

Should I pick bcrypt, Argon2, scrypt or PBKDF2?

For new projects choose Argon2id (OWASP suggests starting at m = 19 MiB, t = 2, p = 1): it’s both memory- and time-hard, which resists GPU cracking best. bcrypt has the most mature ecosystem and is available in almost every language; scrypt is memory-hard as well; PBKDF2 is mostly for FIPS compliance and needs a high iteration count (600,000+ for SHA-256). Never store passwords with fast hashes such as MD5 or plain SHA-256.

Why is the hash different every time for the same password?

A new random salt is generated each time and stored inside the hash string together with the parameters. Verification reads the salt and parameters back out, recomputes, and compares, so many different hash strings can belong to the same password. That’s the point of salting: identical passwords never share a hash in your database, which defeats rainbow tables.

🧂

🧂Bcrypt Generator & Checker - Argon2, scrypt, PBKDF2 Hashes

Building a login, migrating a user table or debugging a “the password is right but login fails” bug often means generating or checking a password hash on the spot. This tool creates hashes with the four mainstream algorithms: bcrypt (cost 4–14 with a $2b$, $2y$ or $2a$ prefix), Argon2 (Argon2id / 2i / 2d with adjustable memory, iterations and parallelism), scrypt (N, r, p) and PBKDF2 (HMAC-SHA1/256/512). The output formats match PHP’s password_hash, Django, Flask/Werkzeug and passlib, and the elapsed time is shown so you can judge cost settings for your server. To verify, paste the hash string and the password: the format and parameters are detected automatically and the hash is recomputed with the same salt. bcrypt, scrypt and Argon2 are implemented in pure TypeScript and were cross-checked against OpenBSD test vectors, PHP, Node.js and Python; PBKDF2 uses the browser’s native WebCrypto. Work runs in a background Web Worker, so high settings never freeze the page and you can cancel at any time. Passwords and hashes are never uploaded or stored.

Free · No sign-up · Runs in your browserLast updated: 2026-10-26

Loading tool...

How to use Bcrypt Generator & Checker

1Pick an algorithm, type the password and adjust cost, memory and output format
2Click Generate, then copy the hash and check how long it took
3Switch to Verify password, paste a hash and a password, and the format is detected for you

FAQ

What bcrypt cost should I use?: Each +1 doubles the work. OWASP recommends at least 10, and 10–12 is common; a practical target is roughly 100–300 ms per hash on your server, and you can get a feel for the timing here (browsers and servers differ). Note that bcrypt only uses the first 72 bytes of a password — anything after that doesn’t change the hash, and the tool warns you about it.
What’s the difference between $2a$, $2b$ and $2y$?: The algorithm is the same; the prefixes mark historical bug fixes. $2a$ is the early version, $2y$ is what PHP adopted after fixing a flaw in its implementation, and $2b$ is OpenBSD’s marker after fixing a length overflow with very long passwords. For passwords up to 72 bytes all three produce the same result and generally verify interchangeably. $2b$ is recommended for new systems (PHP outputs $2y$).
Should I pick bcrypt, Argon2, scrypt or PBKDF2?: For new projects choose Argon2id (OWASP suggests starting at m = 19 MiB, t = 2, p = 1): it’s both memory- and time-hard, which resists GPU cracking best. bcrypt has the most mature ecosystem and is available in almost every language; scrypt is memory-hard as well; PBKDF2 is mostly for FIPS compliance and needs a high iteration count (600,000+ for SHA-256). Never store passwords with fast hashes such as MD5 or plain SHA-256.
Why is the hash different every time for the same password?: A new random salt is generated each time and stored inside the hash string together with the parameters. Verification reads the salt and parameters back out, recomputes, and compares, so many different hash strings can belong to the same password. That’s the point of salting: identical passwords never share a hash in your database, which defeats rainbow tables.