bcrypt Hash & Verify

Hash a password with bcrypt at a cost you choose, or check one against an existing $2y$ hash — computed in your browser.

Why bcrypt rather than a fast hash

SHA-256 is designed to be fast, which is exactly wrong for passwords: a GPU tries billions of candidates a second against it. bcrypt is designed to be slow, and adjustably so — the cost factor is a power of two, and every increment doubles the work.

It is also memory-hard enough to be awkward on a GPU, because the Blowfish key schedule it repeats depends on a 4 kB table that has to be rewritten each round.

Cost 10 — about 100 ms on a modern CPU. The common default.
Cost 12 — about 400 ms. A reasonable target for new systems.
Cost 14 — over a second. Noticeable at login; appropriate for high-value accounts.

Reading a bcrypt hash

$2y$10$N9qo8uLOickgx2ZMRZoMye.IjPeaNmSHiA/eVJHqkbCH0nR5.tJC2
 │  │  └── 22-char salt ── 31-char digest
 │  └── cost (2^10 rounds)
 └── version

The salt is part of the hash, so verification needs nothing else — and two users with the same password still get different hashes.

The version prefix differs by implementation history: $2a$ is the original, $2y$ a PHP variant marking a fixed bug, $2b$ the current OpenBSD one. All three compute the same thing, so a hash from one verifies under another.

The 72-byte limit

bcrypt silently truncates the password at 72 bytes. A longer passphrase adds nothing beyond that point — which matters because a 100-character passphrase feels stronger than it is. Pre-hashing with SHA-256 before bcrypt is the usual fix, at the cost of introducing a null-byte pitfall if done carelessly.

Frequently asked questions

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

A new random 16-byte salt is generated per hash. That is what stops one precomputed table from cracking every account at once, and it is why verification reads the salt back out of the stored hash.

Is the password sent anywhere?

No. bcrypt runs in this page. That is the whole reason to hash a password here rather than on a site that computes it server-side — which would mean sending the plaintext you are trying to protect.

bcrypt or Argon2?

Argon2id is the current recommendation: it is memory-hard in a way bcrypt is not, so it resists GPU and ASIC attacks better. bcrypt remains a sound choice, is available everywhere, and is far better than any fast hash.

Why is cost 14 so slow here?

Because it is supposed to be. 2^14 rounds is 16,384 iterations of the expensive key schedule, and it runs on your device — the same second an attacker pays per guess.