What is the cost factor?

The cost (or work factor) sets how many times bcrypt iterates its key-setup loop: 2 to the power of the cost. Each increment doubles the time to hash, making brute-force attacks proportionally harder. Cost 10 to 12 is typical for production today.

Is my password sent to a server?

No. The bcrypt algorithm runs entirely in your browser using a self-contained JavaScript implementation. Nothing about the password or hash leaves your device.

Why does a higher cost feel slower?

That is by design. Bcrypt is deliberately slow, and the cost factor controls exactly how slow. Generating at cost 14 can take a noticeable fraction of a second, which is the whole point — it slows attackers down too.

Why does the same password give a different hash each time?

Each hash embeds a fresh random 16-byte salt, so identical passwords produce different hashes. Verification still works because the salt is stored inside the hash string and reused during the check.

What does the $2b$ prefix mean?

It is the bcrypt version identifier. $2b$ is the current, recommended variant. The full string format is $2b$cost$salt+hash, where the 22-character salt and 31-character hash follow the cost.

Bcrypt Hash Generator & Verifier

Bcrypt is the password-hashing function of choice for many applications because it is deliberately slow and includes a tunable cost factor. This tool runs a complete bcrypt implementation in your browser so you can generate standard $2b$ hashes or verify a password against an existing hash — useful for building test fixtures, confirming a backend produces compatible output, and showing stakeholders how cost factors affect timing. Nothing is ever sent to a server.

How it works

Bcrypt is built on the Blowfish cipher’s expensive key schedule:

A random 16-byte salt is generated and base64-encoded (bcrypt’s own alphabet).
The password and salt feed EksBlowfishSetup, which runs the key schedule 2^cost times — this is the slow, attack-resisting step.
The constant string OrpheanBeholderScryDoubt is encrypted 64 times with the resulting key schedule to produce the 24-byte hash.
The cost, salt, and hash are assembled into the familiar $2b$cost$saltsalthashhash... string.

Verification re-derives the hash using the salt and cost embedded in the stored string, then compares the result. Because the salt is random per hash, the same password yields different strings each time, yet still verifies correctly.

Tips and notes

Pick a cost where a single hash takes a meaningful fraction of a second on your target hardware; cost 10–12 is common in 2026.
Bcrypt silently truncates passwords longer than 72 bytes — long passphrases beyond that length add no security with bcrypt alone.
Use generated hashes as seed/test fixtures, never reuse a real production password here.
A higher cost is not free: it costs your servers CPU on every login, so balance security against login latency.