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.

What is the Bcrypt Hash Generator & Verifier?

Generate or verify bcrypt password hashes at cost factors 4 to 14 using a self-contained JavaScript bcrypt implementation that runs entirely in your browser. Create test fixtures, verify hash implementations, and demonstrate cost-factor timing — no server, no password sent anywhere. It runs free in your browser on Gera Tools, with nothing uploaded.

Bcrypt Hash Generator & Verifier

Name: Bcrypt Hash Generator & Verifier
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

Choosing the right cost factor

The cost factor is the most important tuning knob when deploying bcrypt. Too low and brute-force attacks become practical; too high and every login introduces noticeable latency for legitimate users. The conventional target is to keep a single hash under 100ms on your login server. What cost achieves that depends on the server hardware — a cost of 10 is often the right call on a modern server, but the only way to know is to benchmark.

The cost demonstration in this tool shows the real timing in your browser, which is a different machine than your server, but it gives an order-of-magnitude feel. Watch how cost 12 feels noticeably slower than cost 10: that extra second is two doublings of the work factor.

The 72-byte truncation

One widely-unknown quirk of bcrypt is that it silently ignores everything past the 72nd byte of the password. Two passphrases that share the same first 72 bytes but differ after that will produce the same hash and both verify as “correct.” In practice, users rarely set passwords long enough to trigger this, but it is worth knowing if you allow very long passphrases. If you need to support arbitrarily long passwords with bcrypt, a common mitigation is to SHA-256 the password first, then bcrypt the hash.

When to verify an existing hash

The verifier mode is useful for confirming that your application produces standard-compatible hashes. If your backend is using a bcrypt library, generate a hash here at the same cost and compare it to your library’s output for the same input — if both verify against each other, the implementations are compatible. This is also helpful when migrating to a new bcrypt library or language: generate a set of hashes with the old library, verify them with the new one, and confirm full compatibility before flipping the switch in production.