What this tool does
bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999. It combines a password, a random 16-byte salt and a cost into a 60-character string: the version ($2b$), a two-digit cost, then 22 characters of salt and 31 of checksum in bcrypt's own Base64 alphabet (./A–Z a–z 0–9). The cost is a power of two: cost 10 runs bcrypt's expensive Blowfish key setup 2^10 = 1,024 times, and each step up doubles the time, which is what makes guessing slow. The salt is stored in the hash, so the same password gives a different hash every time, and checking a password means hashing it again with the stored salt and cost and comparing the checksum. bcrypt reads the password as UTF-8 bytes and uses at most the first 72; the rest is ignored, and the tool warns when that happens. The prefix names the version: $2b$ is current, $2a$ is the older label and $2y$ is PHP's. For ordinary passwords all three compute the same result, and Check mode accepts each of them.
Example input and output
correct horse battery staple$2b$10$PET0SFHncA3nZw/xWUvyGON9jK.F/vNya59kBoh4riCfGFqSebucO
$2b$ version
10 cost: 2^10 = 1,024 rounds
PET0SFHncA3nZw/xWUvyGO salt (16 bytes)
N9jK.F/vNya59kBoh4riCfGFqSebucO checksum (23 bytes)Here the salt is fixed to the 16 bytes of the text “DevPrix.io salt!” so any bcrypt library reproduces this hash. The tool picks a new random salt each time, so your hash will differ and still verify.
Password hunter2
Hash $2y$05$YFPuWVLxb0OeXVffZV/qXO4OeCvOevPgsXoFlar/y9X4PgXI3GFHe✓ Matches
Hunter2 instead: ✗ Does not matchPHP and Apache htpasswd write $2y$, which is the same algorithm as $2b$. The cost (05) and the salt are read from the hash itself.
Our staging database password is long, so surely it is safe from guessing: v1
Our staging database password is long, so surely it is safe from guessing: v2Same hash for both (cost 10, same salt):
$2b$10$PET0SFHncA3nZw/xWUvyGODb3kyubNJMr6wi8UB1Th1/i1DgZZbSOEach line is 77 bytes. bcrypt stops at byte 72, so the “v1” and “v2” at the end are never read and either password matches the other's hash.
Common errors and fixes
- Invalid bcrypt hash
- A bcrypt hash is exactly 60 characters: $2a$, $2b$ or $2y$, a two-digit cost and a $, then 53 characters from ./A–Z a–z 0–9. A shorter value was usually cut off, often by a database column narrower than 60 characters; store bcrypt hashes in CHAR(60) or wider.
- A hash copied from a .env file, shell or Compose file never matches
- Quotes, a backslash before each $ (\$) or doubled $$ signs are escaping, not part of the hash. Paste the plain value that starts with $2. In a shell, put the hash in single quotes: inside double quotes, $2 and $10 are expanded as variables and silently change the value.
- Two hashes of the same password are different
- That is expected: each hash has its own random salt. Never hash a login attempt and compare it with the stored hash as strings. Call your library's verify function (bcrypt.compare, password_verify, checkpw), which re-hashes with the stored salt and cost.
- A long password matches even though its ending is wrong
- bcrypt ignores everything after byte 72, and accented letters and emoji take 2–4 bytes each in UTF-8. Enforce a 72-byte maximum or move to Argon2id, which has no such limit. Some libraries now refuse longer passwords instead; Python's bcrypt 5.0 raises an error.
- A $2b$ hash is rejected by an older system
- Some older bcrypt code only knows $2a$ and $2y$; the htpasswd that ships with macOS, for example, rejects a $2b$ hash it accepts as $2y$. The computation is identical, so changing the prefix to $2y$ (or $2a$) makes the hash verify there.
- Logins are instant, or take seconds
- Costs 4–9 are fast enough to guess at scale and suit only tests. Use at least 10, typically 10–12 in 2026, and time it on your production hardware: each step doubles the work. A cost that makes a login take seconds is a denial-of-service risk under load.
Common use cases
- Creating password hashes for test fixtures, seed data and local development users
- Checking whether a password matches a hash from a database, .htpasswd file or config
- Reading a hash's version, cost and salt when auditing an old user table
- Seeing how long each cost takes before choosing one for an app
- Showing a teammate why every bcrypt hash of the same password is different
Privacy and security notes
- Hashing and checking run in JavaScript in this tab. The password is not uploaded, logged or stored.
- Share links carry only a bcrypt hash, never the password, and a link holding anything other than a bcrypt hash is ignored. A hash can still be attacked offline by guessing, so keep real users' hashes confidential.
- Use test passwords. Don't type production credentials or your users' passwords into any website, this one included; verify those on your own systems.
Frequently asked questions
Why is the bcrypt hash different every time?
Each hash gets a new random 16-byte salt, stored in the hash itself as the 22 characters after the cost. The same password with a different salt gives a different checksum, so identical passwords don't produce identical hashes and precomputed tables are useless. Verification reads the salt back out of the hash.
What bcrypt cost should I use?
At least 10; 10–12 is typical in 2026. Each step doubles the time, so pick the highest your login endpoint can afford under load, measured on your production hardware, and raise it as hardware gets faster. Most libraries can re-hash a password at the new cost on the user's next successful login.
Should I use bcrypt, SHA-256 or Argon2id?
Not plain SHA-256: it is built to be fast, so a single GPU can try billions of guesses per second. For new systems, OWASP's Password Storage Cheat Sheet recommends Argon2id first, then scrypt; bcrypt remains acceptable for existing systems, with a cost of at least 10 and the 72-byte limit in mind. Argon2id is memory-hard, while bcrypt uses about 4 KB of memory, which makes it cheaper to attack with specialised hardware.
Why does bcrypt only use 72 bytes of the password?
The password becomes the key for bcrypt's Blowfish key setup, which reads at most 72 bytes (eighteen 32-bit words). Most libraries silently ignore the rest, and a few now reject longer input. In UTF-8, 72 bytes can be as few as 18 emoji. If you allow long passphrases, enforce the limit or use Argon2id.
What is the difference between $2a$, $2b$ and $2y$?
They label the same algorithm with different histories. $2a$ is the long-standing label. $2y$ was introduced in 2011 by crypt_blowfish, the bcrypt code PHP uses, to mark hashes made after it fixed a bug with non-ASCII characters (hashes from the buggy code could be relabelled $2x$). $2b$ came from OpenBSD in 2014, after its own $2a$ code mishandled passwords longer than 255 bytes. For ordinary passwords all three give the same checksum, and this tool checks any of them.