Bcrypt Hash Generator & Verifier
Turn a password into a $2b$ bcrypt hash, or check a password against a hash you already have. Hashing runs in a Web Worker inside your browser — nothing you type is sent anywhere.
Do not paste a real production password into any online tool — this one included.
Input
Password and cost
A fresh 16-byte salt is drawn for every hash, so the same password gives a different hash each time. That is the point of a salt, not a bug.
Cost 10 means 2^10 = 1,024 key-setup rounds. Every step up doubles the work — for someone grinding a stolen password file, and for your own server on every single login. Most production systems sit between 10 and 12.
The three prefixes produce identical hash bytes for passwords under 72 bytes; only the label differs. PHP’s bundled crypt() does not recognise $2b$, so a $2b$ hash will silently fail password_verify(). Pick $2y$ for PHP.
Hashing runs in a Web Worker inside this tab. The password is never sent to Wespner or anyone else — there is no request to send it in.
Result
bcrypt hash
Press “Generate hash”.
Cost, measured here
What this setting costs you
Estimate: one hash is timed in this tab at cost 8 and every other cost is extrapolated from it by doubling. Your own hardware and browser decide the number.
Those numbers are one JavaScript thread. A real attacker runs native code on a rack of GPUs and is orders of magnitude faster — that gap is exactly why the cost factor has to be uncomfortable rather than convenient. The same slider also decides how much CPU every one of your own logins burns.
Reading the string
What the 60 characters mean
$2b$12$LQv3c1yqBWVHxkd0LHAkCOYUtYgBuLIjrsGrDUgYqZbY7d0RfPbtq
Both blocks use bcrypt’s own base64 alphabet, which starts ./ and puts the digits last — it is not standard base64, and decoding it as though it were gives the wrong bytes. That, plus the 22/31 split, is a quick way to sanity-check that a string really is a bcrypt hash and not something that merely looks like one.
Choosing an algorithm
bcrypt, scrypt or Argon2?
This tool is bcrypt-only on purpose. Here is when it is the right answer and when it isn’t.
Slow by design, but it only leans on CPU time and a fixed 4 KB of memory. GPUs and FPGAs parallelise it far better than they do the newer designs. It is still a perfectly respectable choice, it is supported literally everywhere, and its 72-byte password limit is its most surprising sharp edge.
Adds a tunable memory cost, so an attacker needs RAM per guess, not just cores. Harder to parallelise cheaply than bcrypt.
Winner of the 2015 Password Hashing Competition and what OWASP now suggests for new systems: separate time, memory and parallelism knobs, with the id variant resisting both GPU and side-channel attacks. If you are starting fresh and your platform has it, use it. If you are maintaining something that already stores $2y$ hashes, bcrypt at a sensible cost is not an emergency — rehash on next login instead.
Proof
Check this page against the published test vectors
A hashing tool asking to be trusted should be checkable. These are the reference bcrypt vectors used by OpenBSD-derived implementations; the page recomputes each one from its own salt and compares character by character, then hashes and re-verifies a throwaway password at two cost factors.
The batch runs 6 published vectors plus two round trips.
Running your own game server?
Wespner game servers with DDoS protection, NVMe drives and activation within minutes.