Bcrypt Hash Generator & Verifier
Create and verify bcrypt hashes in your browser, with timing and the 72-byte check.
Hash a password
Verify a password
How long does each cost take?
Hashes a test password at cost 8, 9, 10 … until one takes over 3 seconds. Your server will differ — run the same test there.
| Cost | Rounds | Time | Under 1 second? |
|---|
About the Bcrypt Hash Generator & Verifier
bcrypt (Provos & Mazières, USENIX 1999) is the slow, salted password hash used by countless web frameworks: every hash contains its own random salt and a cost — 2^cost rounds of an expensive key setup — so attackers who steal a database can only guess slowly. This tool hashes a password at any cost from 4 to 16, measures how long it took on your device, and verifies a password against an existing hash, splitting it into version, cost, salt and checksum.
It writes the $2b$, $2a$ or $2y$ labels that different libraries expect, warns when a password is longer than bcrypt's 72-byte limit (and shows exactly which part is ignored), and flags costs below OWASP's minimum of 10. bcrypt runs in a background worker with a progress bar and Cancel, so even cost 16 never freezes the page. Nothing you type is stored or sent.
How to use it
- To hash, type the password, choose the cost (12 is a common choice; OWASP's minimum is 10) and the version label your system expects, then press Generate hash.
- Copy the 60-character hash. A new random salt is used each time, so every hash is different — and all of them verify.
- To check a password, choose Verify, paste the hash (quotes,
{bcrypt}prefixes and htpasswduser:lines are fine), type the password and press Verify password. - Press Measure on this device to see how long each cost takes, then run the same test on your server to choose a cost.
Examples
Password: correct horse battery staple Hash: $2y$04$GVH.9hP9ua06zElrFsirmeFralttQdAvP3WDTfi4Rwhgq0Mkhxk9.
✓ Match — $2y$, cost 4 (16 rounds)
Made with htpasswd -B -C 4; cost 4 is only for tests.
$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
Version $2b$ · cost 12 (4,096 rounds) · salt R9h/cIPz0gi.URNNX3kh2O · hash PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW
22 salt characters hold 16 random bytes, 31 hash characters hold 23 bytes, in bcrypt's own Base64 alphabet (./A–Za–z0–9).
Password A: 72 × "x" Password B: 80 × "x"
Both verify against the same hash
bcrypt never looks past byte 72, so the 8 extra characters change nothing — the tool warns about this.
Common uses
- Creating a password hash for a seed user, test fixture or an admin account inserted directly into a database.
- Checking whether a stored hash matches a password while debugging a login.
- Finding out which version and cost an old database uses before migrating it.
- Measuring how the cost factor affects hashing time before changing it in production.
Choosing the cost
The OWASP Password Storage Cheat Sheet says the bcrypt work factor "should be as large as verification server performance will allow, with a minimum of 10", and gives the rule of thumb that "calculating a hash should take less than one second". Each +1 doubles the time: if cost 12 takes 250 ms on your server, cost 13 takes about 500 ms. When you raise the cost, rehash each user's password the next time they sign in, since that is the only moment you have it.
For new systems OWASP recommends Argon2id (at least 19 MiB of memory, 2 iterations, 1 degree of parallelism) and then scrypt, keeping bcrypt for systems where those are not available. bcrypt is still far better than any fast hash such as SHA-256 or MD5, which must never be used on their own for passwords.
The 72-byte limit
bcrypt only uses the first 72 bytes of a password — bytes of UTF-8, not characters: "é" takes 2 bytes and most emoji take 4. This tool, like bcryptjs, ignores the rest and tells you exactly which characters were ignored; other libraries refuse longer passwords instead, such as Go's x/crypto/bcrypt and Python's bcrypt package. OWASP advises enforcing a 72-byte maximum for bcrypt; pre-hashing longer passwords is possible but has pitfalls (zero bytes in binary digests, "password shucking"), so follow OWASP's pattern of Base64-encoding an HMAC with a separately stored pepper if you need it.
$2a$, $2b$ and $2y$
- $2a$ — the long-standing format; Go's x/crypto/bcrypt and Spring Security write it by default.
- $2b$ — introduced by OpenBSD in 2014 after a length-counter bug with passwords over 255 bytes; written by Python's bcrypt package and bcryptjs.
- $2y$ — crypt_blowfish's label after its 2011 sign-extension bug (CVE-2011-2483); PHP's password_hash() and Apache htpasswd write it.
For the first 72 bytes, correct implementations of all three produce the same hash — only the label differs — so most libraries verify any of them, and a library that rejects one label usually accepts the same hash with another. The original 1999 $2$ format (59 characters; the password is hashed without its terminating zero byte) is still read and verified here. $2x$ marks hashes made with the 2011 bug for passwords with non-ASCII characters; they cannot be verified here.
Limitations
- bcrypt runs here as JavaScript (bcryptjs). Native libraries on a server are usually faster, so measure on your own server before choosing a cost.
- Costs above 16 are not offered: in a browser they take minutes. Hashes with a higher cost (up to 31) can still be parsed and verified, given time.
- $2x$ hashes (from crypt_blowfish versions with the 2011 bug) cannot be verified.
- Passwords and hashes are never saved or sent anywhere; they are gone when you close or reload the page.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
Why is the hash different every time I press Generate?
Each hash gets a new random 16-byte salt, stored inside the hash itself (the 22 characters after the cost). That is intended: identical passwords get different hashes, so attackers cannot use precomputed tables. Verification reads the salt from the hash, so every one of them verifies.
Can a bcrypt hash be decrypted?
No. bcrypt is one-way: the only way back is to guess passwords and hash each guess, which the cost makes slow on purpose. Strong, unique passwords are what keep a stolen hash safe.
Which cost should I use?
At least 10 (OWASP's minimum), and as high as your login server can handle — aim for well under a second per hash. 12 is a common default today. Measure on the server that will run it, not just in your browser.
My library rejects a $2y$ (or $2b$) hash. What can I do?
If the hash is valid, try the same hash with the label changed to the one your library expects ($2a$, $2b$ or $2y$): for normal passwords the rest of the hash is identical. This does not apply to $2x$ hashes.
Is it safe to type a real password here?
The page never sends or stores what you type: hashing and verifying happen in a worker inside your browser, and it works offline. Still, avoid pasting live production passwords into any website you do not need to — test passwords are enough for most debugging.
Should I use bcrypt or Argon2?
For a new system, OWASP recommends Argon2id first, scrypt second and bcrypt only where those are not available. Existing bcrypt hashes with a cost of 10 or more are still considered acceptable; raise the cost over time.