Is my password sent anywhere?

No. The hash is computed in a Web Worker that this page starts, by hash-wasm 4.12.0 loaded from this site, and the page makes no request carrying your password. It is not stored and never goes into the address bar. The one thing remembered, in this browser's local storage, is the cost you last chose.

Why does bcrypt ignore everything after 72 bytes?

bcrypt's key setup cycles the password through Blowfish's 18 subkeys of 4 bytes each, 72 bytes in all, so nothing after the 72nd byte of the UTF-8 text reaches the hash. The letter a is one byte, é is two, € is three and most emoji are four, so the limit can arrive well before 72 characters. This page counts bytes as you type and flags a longer password. The 72-byte case under the tool hashes 72 a's and 72 a's plus é with one salt and gets the same hash for both.

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

Each hash Generate makes gets a new 16-byte salt from crypto.getRandomValues, written as the 22 characters after the cost. A different salt gives a different hash, and verify reads the salt back out of the hash, so every one of them checks as true against the password.

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

They mark revisions of the same algorithm. $2y$ came from crypt_blowfish in 2011, after a bug in how it read non-ASCII bytes, and $2b$ from OpenBSD in 2014, after a bug with passwords over 255 bytes. For text typed here all three give the same hash, so verify reads all three. Generate writes $2a$, the prefix hash-wasm produces. Hashes marked $2x$, the old buggy computation, are not read.

How do I read the parts of a bcrypt hash?

The first four characters are the version, such as $2a$. The two digits after it are the cost, then a $: 10 means 2^10, or 1,024 rounds. The next 22 characters are the salt and the last 31 are the hash itself, both in bcrypt's own base64 alphabet. Every new hash on this page is split into those four parts under it.

How long does each cost take?

Each step in cost doubles the rounds: 4 is 16, 10 is 1,024 and 14 is 16,384. In a test in Chromium on an Apple M4 Pro Mac, cost 10 took about 60 ms and cost 14 about 0.9 s. The page shows the time your own browser took after every hash. That time says nothing about how strong a password is.

Why does verify stop at cost 16?

Every step doubles the work: cost 17 is 131,072 rounds, 8 times cost 14, and cost 20 is 64 times, about a minute at the speed above. This page bounds a check at cost 16: it verifies hashes from cost 4 to 16 and names the cost of any hash above that instead of running it.

Can this decrypt or reverse a bcrypt hash?

No. bcrypt is one-way. Verify answers one question: does the password you typed match this hash, true or false.

What do Cancel and Clear do?

Cancel terminates the worker at once, so no hash comes back, and empties the password on that side. Clear empties the password and the result; on the verify side it also puts the generated hash back in the hash field. The cancel case under the tool starts a cost-14 hash and cancels it 200 ms in.

Bcrypt Generator

Make a bcrypt hash of a password at a cost from 4 to 14, or check a password against an existing hash, on your device. The work runs in a background worker, so the page keeps responding at cost 14 and Cancel stops it at once, and each hash Generate makes gets a new 16-byte salt from crypto.getRandomValues. The password is counted in UTF-8 bytes as you type, and one longer than bcrypt's 72-byte limit is flagged with the bytes that will not change the hash.

generate

cost 10

password

0 characters, 0 of 72 bytes

cost

10 = 2^10 = 1,024 rounds

salt16 random bytes, new each time

the hash appears here

elapsednot run yet

verify

paste a hash, or generate one

password

0 characters, 0 of 72 bytes

hash

reads$2a$, $2b$ and $2y$ hashes; this page writes $2a$

costtaken from the hash, 4 to 16 here

no result yet

elapsednot run yet

each step in cost doubles the rounds: 4 is 16, 10 is 1,024, 14 is 16,384, 16 is 65,536

Cost

10, 1,024 rounds

Password

0 of 72 bytes

Verify

not run

Elapsed

not run

Published vector, password abc$2a$06$If6bvum7DFjUnE9p2uDeDu0YHzrHM6tf.iqN8.yx.jNN1ILEf7h0i
press Run to check it in this browser
72 a's, then 72 a's plus é73 characters, 74 bytes in UTF-8, one salt for both
press Run to hash both here
Cancel at cost 14an example password, cancelled 200 ms in
press Run to start one and cancel it

Accuracy. Generate computes each hash on this device with hash-wasm 4.12.0 in a worker, using a new 16-byte salt from crypto.getRandomValues, and writes the $2a$ prefix; nothing typed here is sent or stored. bcrypt reads at most 72 bytes of UTF-8, so a longer password is flagged and bytes past the 72nd do not change the hash. Cost runs from 4 to 14 when generating and up to 16 when verifying, each step doubling the rounds; the elapsed time is this browser's and says nothing about password strength.

Common questions

Is my password sent anywhere?: No. The hash is computed in a Web Worker that this page starts, by hash-wasm 4.12.0 loaded from this site, and the page makes no request carrying your password. It is not stored and never goes into the address bar. The one thing remembered, in this browser's local storage, is the cost you last chose.
Why does bcrypt ignore everything after 72 bytes?: bcrypt's key setup cycles the password through Blowfish's 18 subkeys of 4 bytes each, 72 bytes in all, so nothing after the 72nd byte of the UTF-8 text reaches the hash. The letter a is one byte, é is two, € is three and most emoji are four, so the limit can arrive well before 72 characters. This page counts bytes as you type and flags a longer password. The 72-byte case under the tool hashes 72 a's and 72 a's plus é with one salt and gets the same hash for both.
Why is the hash different every time for the same password?: Each hash Generate makes gets a new 16-byte salt from crypto.getRandomValues, written as the 22 characters after the cost. A different salt gives a different hash, and verify reads the salt back out of the hash, so every one of them checks as true against the password.
What is the difference between $2a$, $2b$ and $2y$?: They mark revisions of the same algorithm. $2y$ came from crypt_blowfish in 2011, after a bug in how it read non-ASCII bytes, and $2b$ from OpenBSD in 2014, after a bug with passwords over 255 bytes. For text typed here all three give the same hash, so verify reads all three. Generate writes $2a$, the prefix hash-wasm produces. Hashes marked $2x$, the old buggy computation, are not read.
How do I read the parts of a bcrypt hash?: The first four characters are the version, such as $2a$. The two digits after it are the cost, then a $: 10 means 2^10, or 1,024 rounds. The next 22 characters are the salt and the last 31 are the hash itself, both in bcrypt's own base64 alphabet. Every new hash on this page is split into those four parts under it.
How long does each cost take?: Each step in cost doubles the rounds: 4 is 16, 10 is 1,024 and 14 is 16,384. In a test in Chromium on an Apple M4 Pro Mac, cost 10 took about 60 ms and cost 14 about 0.9 s. The page shows the time your own browser took after every hash. That time says nothing about how strong a password is.
Why does verify stop at cost 16?: Every step doubles the work: cost 17 is 131,072 rounds, 8 times cost 14, and cost 20 is 64 times, about a minute at the speed above. This page bounds a check at cost 16: it verifies hashes from cost 4 to 16 and names the cost of any hash above that instead of running it.
Can this decrypt or reverse a bcrypt hash?: No. bcrypt is one-way. Verify answers one question: does the password you typed match this hash, true or false.
What do Cancel and Clear do?: Cancel terminates the worker at once, so no hash comes back, and empties the password on that side. Clear empties the password and the result; on the verify side it also puts the generated hash back in the hash field. The cancel case under the tool starts a cost-14 hash and cancels it 200 ms in.

Generate computes each hash on this device with hash-wasm 4.12.0 in a worker, using a new 16-byte salt from crypto.getRandomValues, and writes the $2a$ prefix; nothing typed here is sent or stored. bcrypt reads at most 72 bytes of UTF-8, so a longer password is flagged and bytes past the 72nd do not change the hash. Cost runs from 4 to 14 when generating and up to 16 when verifying, each step doubling the rounds; the elapsed time is this browser's and says nothing about password strength.