Generate a bcrypt hash from a password, or check whether a plain-text password matches a hash you already have. Everything runs in your browser.
0 bytes
Each increment of one doubles the work. In production, aim for around 250 ms per hash.
$2b$10$...
Bcrypt is a password derivation function designed in 1999 on top of the Blowfish cipher. Unlike SHA-256, which aims to be as fast as possible, bcrypt aims to be deliberately slow and, on top of that, tunable: the cost factor sets how many iterations run, and each increment of one doubles the work. Cost 12 takes twice as long as cost 11 and sixteen times as long as cost 8.
That slowness is the entire defence. An attacker who obtains a database of hashes will brute-force candidates, and their speed depends directly on the cost of each attempt. With unsalted SHA-256, a modern GPU tries billions of passwords per second. With bcrypt at cost 12, we are talking a few thousand. That seven-order-of-magnitude gap is what turns a database dump into a manageable problem rather than an immediate catastrophe.
Bcrypt also embeds the salt inside the hash itself. The result looks like $2b$12$... where 2b is the version, 12 the cost, and what follows is the salt and hash together. Because the salt differs for every password, two users with the same password get different hashes, and precomputed rainbow tables stop working. That is why there is no need to store the salt separately: it travels with the hash.
There is one known limitation worth keeping in mind: bcrypt only considers the first 72 bytes of the input, so a very long passphrase is silently truncated. For new designs, Argon2id is the current recommendation because it is memory-hard as well, which frustrates attacks with specialised hardware. Bcrypt remains perfectly acceptable and is thoroughly battle-tested; what you must not do under any circumstances is store passwords with SHA-256, MD5 or any fast hash.
