Bcrypt Generator & Checker
Hash passwords with bcrypt and verify them against a hash. Runs in your browser.
About this bcrypt generator & checker
This bcrypt generator turns a password into a salted bcrypt hash, and its checker tells you whether a password matches an existing hash. It is for developers seeding a test database, debugging a login, or checking what a framework stored.
You pick the cost factor from 4 to 14 and the version prefix ($2b$, $2a$ or $2y$). Every hash gets a fresh 16-byte salt from crypto.getRandomValues, so the same password gives a different hash each time. That is normal, and the checker still matches it.
The hashing runs in a background worker inside your browser. A cost 14 hash can take a few seconds, and you get a progress bar and a Cancel button instead of a frozen tab. Nothing you type is sent anywhere.
Features
Generate and verify in one place
Make a hash, then press Verify this hash to test it straight away, or paste any 60-character hash from your database and check a password against it.
Cost 4 to 14 with real timing
The tool measures how long each hash took on your device and estimates the next cost from that. Each step up doubles the work, and you can see it.
72-byte limit warning
A live meter counts UTF-8 bytes, not characters. If a password goes over 72 bytes, you see exactly which part bcrypt will ignore.
Hash anatomy
Every hash is split into its version, cost, 22-character salt and 31-character hash, color coded, so you can read what a stored value means.
Clear errors for the wrong kind of hash
Paste an Argon2 string, an MD5 digest or a truncated bcrypt hash and the checker says what it is and what to do, instead of a bare "invalid".
Constant-time comparison
The final match check compares every character, so the result doesn't leak where two hashes differ.
How to use the bcrypt generator & checker
- 1Type a password and pick a cost factor and version prefix.
- 2Press Generate hash to get a salted 60-character bcrypt hash.
- 3Switch to Verify password to check a password against any bcrypt hash.
When to use it
Seed a test user
Generate a hash for a known password and paste it into a migration or fixture file so you can log in on a fresh dev database.
Debug a failing login
Copy the stored hash from the users table and test the password the user says they typed. If it matches here, the bug is in your code, not the password.
Check a framework's output
PHP's password_hash() writes $2y$, Node's bcrypt writes $2b$, and some older libraries write $2a$. Paste any of them to confirm it is well formed.
How does bcrypt work?
Bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières. It is built on the Blowfish cipher, with a deliberately expensive key setup called EksBlowfish.
The cost factor is a power of two. Cost 10 runs the key setup 2^10 = 1,024 times. Cost 12 runs it 4,096 times, so it takes about four times longer. That slowness is the point. A login check that takes 100 milliseconds is fine for you, but it caps an attacker at a few thousand guesses per second per CPU core.
The salt is 16 random bytes, stored in the hash itself. You never store it separately. When you verify, bcrypt reads the cost and salt back out of the hash, runs the same work on the password, and compares the result.
What do $2a$, $2b$ and $2y$ mean?
They are version markers, and for passwords under 72 bytes they all produce the same hash.
- $2a$: the long-standing marker. Early OpenBSD code had a length bug with passwords of 255+ bytes, which is why $2b$ exists.
- $2b$: the current OpenBSD marker, introduced in 2014 after that fix. Most modern libraries default to it.
- $2y$: PHP's marker, added in 2011 to flag hashes made after a bug fix in the crypt_blowfish library. PHP verifies $2a$ and $2b$ too.
- $2x$: flags hashes made by the old buggy crypt_blowfish code. They can't be checked reliably, so this tool refuses them and you should rehash.
Why does bcrypt only use 72 bytes?
Blowfish takes a key of up to 72 bytes, so bcrypt silently ignores anything after that. A 100-character password and its first 72 bytes give the same hash.
Bytes are not characters. Plain English letters are 1 byte each in UTF-8, but é is 2 bytes, most Chinese characters are 3, and an emoji is 4. A 20-emoji password is already 80 bytes. The meter in the tool counts bytes for this reason.
If you need longer secrets, a common fix is to pre-hash the password with SHA-256 and encode it as Base64 before bcrypt. You can see what that step produces with the SHA-256 hash generator. Newer systems often choose Argon2id instead, which has no such limit.
What cost factor should I use?
OWASP's Password Storage Cheat Sheet sets a minimum cost of 10 for bcrypt. Many teams use 12. Benchmark on your own login server and pick the highest cost that keeps one check comfortably under a quarter of a second.
Why use Mavros
| Mavros | Typical upload sites | |
|---|---|---|
| Where hashing happens | In your browser, in a background worker | Often posted to a server |
| High cost factors | Progress bar and Cancel, page stays usable | Tab freezes until done |
| 72-byte limit | Live UTF-8 byte meter shows the ignored part | Not mentioned, or a line in the FAQ |
| Version prefix | Choose $2b$, $2a$ or $2y$; verifies all three | One fixed prefix |
| Wrong hash pasted | Explains whether it's Argon2, MD5 or truncated | "Invalid hash" |
| Timing | Measured per hash, with estimates per cost | Not shown |
Tips
- Never store a bcrypt hash in a column shorter than 60 characters. A truncated hash will never match, and the checker here will tell you it is cut short.
- Generate test passwords with the random password generator, then hash them here for your fixtures.
- Bcrypt protects stored passwords, not weak ones. Run a candidate through the password strength checker to see how quickly it would fall in an offline attack.
- To sign API requests or webhooks, you want a keyed hash, not bcrypt. Use the HMAC generator for that.
Questions
Can a bcrypt hash be decrypted?
No. Bcrypt is a one-way function, so there is nothing to decrypt. The only way to find the password is to guess candidates and hash each one, which the cost factor makes slow on purpose.
Why does the same password give a different bcrypt hash each time?
Because every hash uses a new random 16-byte salt. The salt is stored inside the hash (the 22 characters after the cost), so the checker can still verify the password against any of them.
How do I verify a password against a bcrypt hash?
Switch to Verify password, type the password, paste the full 60-character hash and press Check password. The tool reads the cost and salt from the hash, recomputes it, and shows Match or No match.
Is it safe to hash a real password here?
Yes, the password stays on your device. Hashing runs in a browser worker and nothing is sent or stored. Still, avoid pasting live production credentials on a shared or untrusted computer.
What is the difference between $2a$, $2b$ and $2y$?
They are version markers that produce identical hashes for normal passwords. $2b$ is the current standard, $2y$ is PHP's marker and $2a$ is the older one. Most libraries verify all three.
What happens to passwords longer than 72 bytes?
Bcrypt ignores everything after the first 72 bytes. Two passwords that share those 72 bytes give the same hash, so the extra length adds no security. The byte meter shows where the cut falls.
Should I use bcrypt or Argon2id?
Both are acceptable. OWASP lists Argon2id first for new systems because it also uses a lot of memory, which slows GPU attacks. Bcrypt is fine when your stack already supports it, at cost 10 or more.