Bcrypt Hash Generator & Verifier
Hash a password with bcrypt at any cost factor from 4 to 31, or paste an existing $2a$, $2b$ or $2y$ hash and check a password against it. The cost and salt are read out of the hash.
Bcrypt hash
Type a password and its hash appears here.
4 to 31 is bcrypt's own range
How to use
- Leave the mode on Hash and type the password into the Password box.
- Drag the Cost factor slider or type a number into the Cost box beside it. It opens at 10, the line underneath says how long that cost takes here, and 10 to 12 is where most web apps sit.
- Up to the marked cost the hash appears as you type. Past it, press Hash again: a bar fills as the rounds run, and Stop ends the run and keeps the hash you had.
- Press Copy hash and store the whole 60-character string. The salt is inside it.
- To check a password instead, choose Verify under Mode. The cost slider disappears and a Bcrypt hash box takes its place, since the cost comes from the hash now.
- Paste the stored hash into that box and type the password you are testing. Check this hash, under a fresh hash, carries it across for you.
- Read the verdict under the settings. Match means the password fits, and the line under the hash names its version and the cost it was created at.
About this tool
Bcrypt is deliberately slow, and that is the part nobody expects the first time. SHA-256 hands back a digest before your finger leaves the key. Bcrypt repeats an expensive key-setup step instead, governed by a cost factor, which you will also see called work factor or rounds, and every step up the slider doubles the work. Cost 10 comes back in a fraction of a second. Cost 15 is thirty-two times that and you will watch it happen, so the line under the slider names the time for the cost under the thumb, measured on your own device.
The page has two modes, Hash and Verify. Hash takes your password plus whatever the slider says and gives you one 60-character string: the $2b$ prefix, two digits of cost, then the salt and the digest packed together, each part in its own colour. Store that whole string, salt included, because verification reads the salt back out of it. Verify runs the other direction. Paste the stored hash, type the password, and the verdict appears as you type: Match or No match, with the version and cost read out of the hash. It reads $2a$, $2b$ and $2y$ hashes, so a hash from an old PHP app checks out fine even though everything it writes is $2b$. A fresh random salt goes in each time, which is why hashing the same password twice never gives you the same string.
Three things to know first
- Bcrypt reads only the first 72 bytes of a password. The Password box says so once you pass them, but the rest is still dropped, so two passphrases that share their first 72 bytes verify against each other. Run it through SHA-256 first if every character has to count.
- The times beside the slider are predictions. The page times one cost-8 hash when it loads and doubles from there, tightening the guess each time it hashes, so a busy tab or a laptop on battery makes every figure run long.
- Hashing here runs in JavaScript, which is slower than the native bcrypt binding your server most likely uses. A cost that feels sluggish on this page can be perfectly comfortable in production, so time it on the machine that will actually do the work before you settle on a number.
Frequently asked questions
What cost factor should I actually pick?
10 to 12 for a normal web app, raised as your hardware gets faster. The usual way to choose is to take the highest cost your sign-in endpoint can absorb without anyone noticing, which for most people lands somewhere near a quarter of a second on the server. The slider allows 4 through 31 because that is the range bcrypt itself defines. Cost 4 is for test suites, where you want the hashing over and done with before the assertion runs.
Why does the same password give me a different hash every time?
A fresh random salt goes into every hash, and it is stored inside the output string rather than kept alongside it. Precomputed rainbow tables are useless against that, because the attacker would need one table per salt. Verification still works because the salt is read straight back out of the hash you paste in, which is also why Verify mode has no cost slider.
Can I verify a $2a$ or $2y$ hash from an old PHP app?
Both are accepted. The three prefixes are versions of one algorithm: $2a$ is the original, $2y$ came out of the 2011 crypt_blowfish fix for how 8-bit characters were handled, and $2b$ is what everything writes today. Paste any of the three into Verify and it works. Hash mode only ever writes $2b$. What the box rejects is a string that is not shaped like a bcrypt hash at all, since it wants a two-digit cost followed by exactly 53 characters.
Should I paste a real production password in here?
No, and not for any reason peculiar to this page. A credential typed into any browser window can end up in a screenshot, a session recording, an autofill store or somebody else's line of sight. Use it on throwaway strings, or on a hash you are trying to make sense of. Live user passwords belong in your own sign-up path, where the plaintext never leaves the request that carried it.
Missing something in Bcrypt Hash Generator & Verifier? Suggest a feature →
Tell someone who needs this.