glunty Bcrypt Hash Generator and Verifier
Generate a bcrypt hash or verify a password against one. Runs locally; your password never leaves the browser.
- Runs in your browser
- No sign-up
- No watermark
- No installs
Cost 10 is a common default. A cost above 12 can take several seconds in a browser because each step up doubles the work.
This runs entirely in your browser and is meant for learning, testing, and checking hashes. A production login system must hash passwords on the server side; do not rely on client-side hashing to protect real accounts, and do not paste real production passwords into any web tool.
What this tool does
This tool creates and checks bcrypt password hashes without leaving your browser.
In Hash mode you type a password, pick a cost factor, and get a
bcrypt hash string that begins with $2b$. In Verify
mode you paste a password and a bcrypt hash, and the tool tells you whether they
match. Bcrypt is purpose-built for passwords: it is intentionally slow, and it
generates and embeds a random salt in every hash so identical passwords still
produce different output.
How to use it
To hash: choose Hash a password, enter the password, and pick a
cost factor. The cost factor is the base-2 logarithm of the number
of rounds, so 10 means 2^10 (1024) iterations and each step up doubles the work.
Click Generate hash. Above cost 12 the browser can take several
seconds, so the button shows a "Working..." state and the time it took appears below
the result. Copy the hash with the Copy button. To verify: choose
Verify a password, paste the password and the full hash (including
the $2b$10$ prefix), and click Check. A hash of the
password password at cost 10 looks like
$2b$10$rKv8DSTPK9GIQVDrPBnLke...; verifying that same password against
it returns a match, and any other password returns no match.
Common use cases
- Learning how bcrypt hashes are structured and how the cost factor changes timing.
- Checking a password against a bcrypt hash you already have, without wiring up a script.
- Generating a throwaway bcrypt hash as a test fixture or seed value.
- Comparing timings across cost factors to pick a work factor for your own backend.
- Confirming that a stored hash and a candidate password actually match during debugging.
Common pitfalls
- Do not ship client-side hashing as your login. This runs locally, which is great for learning and checking, but a real authentication system must hash the password on the server so the plaintext is verified server-side and the work factor stays under your control. Hashing only in the browser does not protect an account.
- The salt is inside the hash. Bcrypt embeds a random salt in the output, so you never store the salt separately, and you never see two identical hashes for the same password. Verification reuses the embedded salt automatically, so it needs only the password and the full hash string.
- Cost factor is a log scale. Moving from 10 to 12 does not add two rounds, it multiplies the work by four (2^12 vs 2^10). Pick a value that is slow enough to deter attackers but fast enough for your server under load. In a browser, very high cost factors can freeze for seconds.
- Only the first 72 bytes count. Bcrypt ignores input past 72 bytes. Long passphrases can silently hit that ceiling; pre-hash with SHA-256 first, or use a newer function such as Argon2, if you need to support long secrets.
Frequently asked questions
- What is bcrypt and why use it for passwords?
- Bcrypt is a password hashing function built on the Blowfish cipher. It is deliberately slow and has a tunable cost factor, which makes brute-force guessing expensive. Unlike a plain hash such as SHA-256, bcrypt is designed specifically for storing passwords: it bundles a random salt into every output and lets you raise the work factor as hardware gets faster.
- What is the cost factor (rounds)?
- The cost factor is the base-2 logarithm of the number of internal iterations. A cost of 10 means 2 to the power of 10, or 1024, key-setup rounds; a cost of 12 means 4096. Each step up doubles the work, so a hash at cost 12 takes about four times as long as one at cost 10. Higher is more secure but slower. Ten to twelve is a common range for server use.
- Where is the salt stored in a bcrypt hash?
- Bcrypt embeds the salt inside the output string, so you do not store it separately. A hash looks like $2b$10$ followed by 22 characters of base-64 salt and then 31 characters of the hash itself. The $2b$ marks the algorithm version and the 10 is the cost factor. Because the salt travels with the hash, verification needs only the password and the full hash string.
- Is my password sent anywhere when I hash or verify here?
- No. The bcrypt library is bundled into this page and runs entirely in your browser. Your password and the resulting hash are never transmitted. You can confirm this by opening your browser DevTools, switching to the Network tab, and watching that no request is made when you click Generate or Check.
- Can I use this tool for a real login system?
- Use it for learning, for checking a hash you already have, or for generating a test fixture. Do not build production authentication around client-side hashing. In a real system the server must hash the password so the plaintext is verified server-side and the work factor is controlled centrally. Hashing in the browser alone does not protect an account.
- Why does the same password produce a different hash each time?
- Every time you hash, bcrypt generates a fresh random salt and mixes it in, so two hashes of the same password almost never match byte for byte. That is intentional: it stops attackers from precomputing a single rainbow table that works against many accounts. Verification still succeeds because the salt is embedded in the stored hash and reused during the compare.
- What is the maximum password length bcrypt supports?
- The bcrypt algorithm only reads the first 72 bytes of the input; anything beyond that is ignored. For most passwords this never matters, but very long passphrases or pre-hashed inputs can silently hit the limit. If you need to support long secrets, hash them with something like SHA-256 first and feed the result into bcrypt, or use a newer function such as Argon2.
Cite this tool
For academic, journalistic, or technical references. Pick a format:
Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.