ToolFeather
Developer / SEORuns in your browser

Bcrypt Generator & Checker

Create a bcrypt hash at the cost factor you choose, or check whether a password matches an existing hash, with the hash's version, cost and salt explained. Nothing leaves your browser.

Quick presets

Bcrypt Generator & Checker

Generate a hash
12
Each step doubles the work. 10–12 is typical for logins in 2026; benchmark on your own server.
Check a password against a hash

Hashing runs in your browser with bcrypt.js. Passwords and hashes never leave this page and aren't saved in share links.

Runs in your browser. Passwords aren't sent, stored or put in share links.

ToolFeather · Cost 4–15
Scratchpad auto-saved
Stored in this browser (localStorage)
Step-by-step~40s read

How it works — in four simple steps

No signup and nothing to install — it all runs in your browser.

1

Type a password

Or paste a test value.

2

Choose the cost

10–12 is typical; each step doubles the time.

3

Hash it

Copy the result into your app or database.

4

Check later

Paste a password and hash to see if they match.

Pro tip

Pick the cost that takes about 250 ms–1 s on your server, and raise it as hardware gets faster.

Features

Any cost factor

4 to 15, with live timing so you can choose a sensible cost.

$2a$, $2b$ or $2y$

The prefix your language or framework expects.

Check a hash

Verify a password against any bcrypt hash.

Hash anatomy

Version, cost, salt and hash parts highlighted and explained.

72-byte warning

Flags passwords longer than bcrypt can use.

Private

Runs in your browser; passwords aren't stored or shared.

About the Bcrypt Generator & Checker

bcrypt is a password-hashing function designed in 1999 to be deliberately slow. Its cost factor sets how many rounds of the expensive Blowfish key setup run: cost 12 means 212 = 4,096 rounds, and each step up doubles the time. Because every hash includes a random 128-bit salt, hashing the same password twice gives different results, and attackers can't use precomputed tables. A bcrypt hash such as $2b$12$… holds everything needed to check it: version, cost, the 22-character salt and the 31-character hash.

To check a password, bcrypt reads the cost and salt from the stored hash, hashes the password again the same way and compares. That's what Check does here. The prefixes $2a$, $2b$ and $2y$ are interchangeable for normal passwords: $2b$ is the current OpenBSD standard, and $2y$ is PHP's name for the same thing. One limit to know: bcrypt uses only the first 72 bytes of a password, and the tool warns when yours is longer.

Pick a cost that takes roughly a quarter to one second on your production server. That's commonly 10–12 today, and you should raise it as hardware gets faster. For new systems, OWASP's guidance prefers Argon2id, with bcrypt as a solid alternative. Hashing here uses the open-source bcrypt.js library, served from this site, and the passwords you type aren't sent anywhere or saved in share links.

Frequently asked questions

6 answers
What cost factor should I use for bcrypt?
The highest your servers can afford, aiming for about 250 ms–1 s per hash. That's commonly 10–12 in 2026. Re-hash with a higher cost when users log in, as hardware improves.
Why is the hash different every time?
Each hash uses a new random salt, which is stored inside the hash. Checking still works, because bcrypt reads the salt back out of the stored hash.
What's the difference between $2a$, $2b$ and $2y$?
They mark fixes to old implementation bugs. For normal passwords they produce the same hash: $2b$ is the current standard and $2y$ is PHP's label. Most libraries accept all three.
Is there a password length limit?
bcrypt uses only the first 72 bytes. Characters beyond that, including multi-byte UTF-8 characters that push you past 72, don't affect the hash.
Should I use bcrypt or Argon2?
OWASP recommends Argon2id for new systems and bcrypt where Argon2 isn't available. Both are far better than plain SHA-256 or MD5 for passwords.
Is it safe to type a real password here?
Hashing runs entirely in your browser and nothing is sent or saved. Still, for real production credentials, hashing on your own server is good practice.