bcrypt · hash and check
Bcrypt Generator
Create a bcrypt hash of a password with the cost factor you choose, or check whether a password matches a bcrypt hash. Everything runs on your device.
Type a password and press "Generate hash".
A bcrypt hash belongs in your server's database, created by your server code. Use this tool for test data and for checking hashes - not as a step in a production login.
Hashed in your browser with bcrypt.js in a background worker. Nothing is sent or stored. Verify it
What Is bcrypt?
bcrypt is a password hashing function designed by Niels Provos and David Mazières and published in 1999. Unlike fast hashes such as SHA-256, it is deliberately slow, and its slowness is adjustable: the cost factor sets how many rounds of work each hash takes. That makes guessing passwords from a stolen database expensive, and the cost can be raised as computers get faster.
bcrypt also adds a random salt to every hash, so two users with the same password get different hashes, and precomputed tables of hashes are useless.
How to Read a bcrypt Hash
A bcrypt hash is 60 characters and carries everything needed to check a password later. This one is a published test vector for the password U*U:
$2a$05$CCCCCCCCCCCCCCCCCCCCC.E5YPO9kmyuRGyh0XouQYb4YMJKvyOeW
| Part | Value | Meaning |
|---|---|---|
| Version | $2a$ | Which variant wrote it: $2a$, $2b$ or $2y$ |
| Cost | 05 | 25 = 32 rounds of the expensive key setup |
| Salt | CCCCCCCCCCCCCCCCCCCCC. | 22 characters: 128 random bits |
| Hash | E5YPO9kmyuRGyh0XouQYb4YMJKvyOeW | 31 characters: the result |
bcrypt uses its own Base64 alphabet (./A-Za-z0-9). To check a password, a library reads the version, cost and salt from the stored hash, hashes the password the same way and compares the result.
Choosing the Cost Factor
The cost is a power of two, so each step doubles the time: cost 13 takes twice as long as 12, and cost 16 sixteen times as long. The OWASP Password Storage Cheat Sheet asks for a cost of at least 10, and as high as your login servers can handle. This tool defaults to 12 and shows how long each hash took in your browser, to give you a feel for the doubling.
A higher cost is not free: every login pays it on your server, and an attacker can try to exhaust your servers with many login attempts. Pick the highest cost that keeps a login comfortably fast under load, and raise it over time - rehash each password with the new cost the next time its owner logs in.
The 72-Byte Limit
bcrypt uses only the first 72 bytes of a password. Bytes, not characters: in UTF-8 an accented letter takes two bytes and many other scripts three or four, so a password of 30 Cyrillic letters is already 60 bytes. The tool counts the bytes as you type and warns when part of the password would be ignored.
OWASP suggests enforcing a maximum of 72 bytes when you use bcrypt, and NIST requires that the whole password is checked rather than silently cut. Pre-hashing a long password with a fast hash before bcrypt has pitfalls of its own - the password storage guide explains them, and why Argon2id avoids the issue.
A Hash, Not Encryption
A bcrypt hash cannot be turned back into the password, and it is not meant to be. Your application never needs the original: at login it hashes what the user typed with the stored salt and cost and compares. If you need to get data back later, you need encryption instead - see hashing vs encryption.
Bcrypt Generator FAQs
Is it safe to type a real password here?
The password is hashed in your browser and is not sent, stored or put in the address; the fields are cleared when you leave the page. Still, the safest habit is to hash real production passwords only in your own server code. This tool is ideal for test fixtures, seed data, config files and checking what a stored hash contains.
Why do I get a different bcrypt hash every time?
Because each hash gets a new random salt, and the salt is part of the result. Two different hashes of the same password both verify - bcrypt reads the salt and cost back from the hash when it checks a password.
Can a bcrypt hash be decrypted?
No. bcrypt is a one-way password hashing function, not encryption. The only way back is guessing passwords and hashing each guess, and bcrypt's cost factor makes every guess deliberately slow.
What cost factor should I use?
OWASP asks for at least 10, and as high as your server can afford when users log in. Each step doubles the time. Measure on your own server: the time shown in this tool is your browser's, which can be slower or faster than your server.
Should I use $2b$ or $2y$?
Whatever your system expects. Current implementations compute the same hash for both; the label differs. Most libraries write $2b$, while PHP and Apache use $2y$ - Apache's htpasswd does not accept a $2b$ hash. Both are checked correctly by this tool, as is the older $2a$.
Is bcrypt still a good choice?
It is acceptable, especially in existing systems. For new systems OWASP lists Argon2id first, then scrypt, with bcrypt for legacy systems. See how passwords should be stored for current parameters.
Related guides
How Passwords Should Be Stored
