Make a bcrypt hash with a cost from 4 to 15, or check a password against an existing hash.
To generate a bcrypt hash, type a password, pick a cost from 4 to 15 and press Hash password: the tool returns a 60-character string made of a prefix, a cost, a random 22-character salt and a 31-character digest. In $2b$10$ followed by 53 characters, $2b$ is the version, 10 is the cost, the next 22 characters are the salt and the last 31 are the digest. The salt is 16 random bytes from your browser, so the same password gives a different hash every time. That is why a password is checked by recomputing, not by comparing two hashes: the Check mode reads the salt and cost from the hash you paste, hashes the password again and compares all 60 characters. A published example: the password U*U with the salt CCCCCCCCCCCCCCCCCCCCC. and cost 5 gives $2a$05$CCCCCCCCCCCCCCCCCCCCC.E5YPO9kmyuRGyh0XouQYb4YMJKvyOeW. The Check mode has a button that loads it.
The cost is the work factor. bcrypt repeats its key setup 2 to the power of the cost times, so cost 10 means 1,024 rounds, cost 12 means 4,096 and cost 15 means 32,768. Each step up doubles the time. OWASP's Password Storage Cheat Sheet says that for legacy systems using bcrypt you should use a work factor of 10 or more, and that bcrypt should only be used where Argon2 and scrypt are not available. This page allows 4 to 15. Below 10 is for tests only. Above 12 the page warns you, because it can take several seconds; the result shows the time it took on your device, and a Cancel button stops a long run. The work runs in a background task so the page stays usable.
bcrypt reads at most 72 bytes of a password, and it counts bytes, not characters. Your text is converted to UTF-8 first, so an ASCII letter is one byte, é is two, € is three and an emoji is four. A password of 20 emoji is 80 bytes, and the last 8 are ignored. The tool tells you when this happens, and two passwords that share the first 72 bytes give the same digest for the same salt. A password cannot contain the NUL character (U+0000), because bcrypt stops reading at the first one. An empty password can be checked but not hashed here. Text up to 10,000 characters is accepted.
The prefix says which version of the algorithm wrote the hash. $2a$ has been used since 1997. In 2011 a bug was found in one implementation that mishandled password characters above 127, and the prefixes $2y$ (crypt_blowfish) and later $2b$ (OpenBSD 5.5) were added for correct handling; they behave the same, and the crypt_blowfish manual says new hashes should use $2b$ or $2y$. PHP and Apache htpasswd write $2y$. This tool computes all three the same way and does not support the old $2x$ prefix. The implementation is plain JavaScript with no library. It reproduces 10 public test vectors from crypt_blowfish 1.3 and was cross-checked with hashes made and verified by Apache htpasswd. It cannot tell you whether a hash is strong, and it is not a replacement for a server-side library. The password is processed in your browser and is not uploaded or stored; only the cost and prefix you choose are remembered.
Type a password, set the cost (10 is the default), choose a prefix and press Hash password. You get a 60-character string such as $2b$10$ followed by the salt and digest. Copy it into your database, your .htpasswd file or your code.
OWASP's Password Storage Cheat Sheet says to use a work factor of 10 or more for legacy systems that use bcrypt. Cost 10 is 1,024 rounds and cost 12 is 4,096. Pick the highest value your login server can bear, and note that every step up doubles the time.
Each hash starts with a new random 16-byte salt, stored inside the hash itself. Two hashes of the password tiger differ in the salt and digest, and both are valid. To test a password, use Check, which reuses the salt from the hash.
Choose Check a password, enter the password, paste the 60-character hash and press Check password. The tool hashes the password again with the salt and cost in the hash and shows Match or No match. It checks costs from 4 to 15.
$2a$ is the oldest prefix, in use since 1997. After a 2011 bug with characters above 127, $2y$ and then $2b$ were added with identical, correct behavior, and new hashes should use one of them. PHP and Apache htpasswd write $2y$. Some older systems treat non-ASCII bytes differently under $2a$, so prefer $2b$ or $2y$.
No. The password is processed in your browser, in this tab, and no server receives it. Your choices of cost and prefix are saved in this browser; the password and the hash are not.