Can a bcrypt hash be decrypted?

No. bcrypt is a hash, not encryption. The only way to find the password is to try candidates one by one, and the cost exists to make that expensive. To check a password, use the Check password tab.

Why does the same password produce different hashes?

Because each hash has a random salt, stored in the 22 characters after the cost. Verification reads that salt, redoes the computation and compares. Every hash generated for the same password validates.

Which bcrypt cost should I use?

Between 10 and 12 in production, depending on the server. Measure it: a login should take a few tens of milliseconds. In automated tests, 4 is enough. Each point doubles the time, so 14 takes four times longer than 12.

What's the difference between $2a$, $2b$ and $2y$?

Only their history of fixes. For passwords up to 72 bytes, current libraries produce the same hash with all three and accept all three when verifying. Pick the prefix your system already uses so the seed matches the other records.

The login fails even with the right password. What should I check?

Check the password against the hash here. If it matches, the problem is elsewhere: looking up the wrong user, a space in the e-mail, a cache or another environment. If it doesn't, see whether the hash is complete (60 characters), whether .env or the shell cut the $ and whether the password is longer than 72 bytes.

Do passwords longer than 72 characters work with bcrypt?

They work, but only the first 72 bytes count. Two passwords that differ only after that pass each other's verification. The counter on this page shows the bytes and warns when the limit is exceeded.

Argon2id is OWASP's most recent recommendation for new systems and also uses memory to make GPU attacks harder. bcrypt remains acceptable and is the default in Laravel, Spring Security and Devise, which is why this page generates and checks it.

Is the password sent to a server?

No. bcrypt runs in a Web Worker in your browser. The password isn't sent, doesn't go into the URL and isn't saved in the browser, and the field asks the browser not to offer to save it. Metrics record only the cost used and whether the check matched.

Bcrypt generator and checker

Hash a password with bcrypt for your test user's seed or migration, or check whether a password matches the hash stored in the database. Configurable cost, $2b$, $2a$ and $2y$ prefixes, and the work runs in the background without freezing the page.

Use it for test data, seeds and login debugging. The password is the one you type: this page doesn't create passwords.

What to do

Password

0 of 72 bytes

Cost: 10

416

Each extra point doubles the time. 10 to 12 is common in production; 4 keeps automated tests fast.

Estimate on this device: measuring…

Prefix

Current default. Node (bcrypt, bcryptjs), Python and Go.

All three produce the same hash for the same password and salt; only the label changes. Use the one your system stores so the seed matches the other records.

Type a password to generate the hash.

Need MD5 or SHA-256 for a checksum, not a password? Use the hash generator.

Generate hash

What is bcrypt

bcrypt is a password hashing algorithm created in 1999, based on the Blowfish cipher. It draws a 16-byte salt for each password and repeats the work 2 to the power of the cost times. The result holds everything needed to verify later: prefix, cost, salt and hash, in a 60-character string. That's why the same password produces a different hash every time, and verification uses the salt stored inside the hash itself.

Why not MD5 or SHA-256 for passwords

MD5 and SHA-256 were designed to be fast: a graphics card tests billions per second. If the database leaks, common passwords show up in minutes. bcrypt is slow on purpose. At cost 12, each attempt takes tens of milliseconds, which doesn't matter for one login and makes testing millions of passwords impractical. A single fixed salt for the whole system doesn't help, because the attacker only has to rebuild the table once.

How to choose the cost

The cost is the exponent: 10 runs 1,024 rounds, 12 runs 4,096. Choose the highest value your server handles without making login slow, and raise it over time. In automated tests, cost 4 keeps the suite fast without changing the logic, as long as production code reads the cost from configuration. The hash stores its cost, so old passwords keep validating after the change.

The 72-byte limit

bcrypt only uses the first 72 bytes of the password and silently ignores the rest. These are UTF-8 bytes, not characters: é and ñ count as 2, an emoji as 4. Some libraries reject longer passwords, others truncate. If your system accepts long passphrases, cap the length at sign-up or pre-hash the password, as Django does.

$2a$, $2b$ and $2y$

$2a$ is the 1999 version. In 2011 a bug in PHP's implementation led to $2y$, which marks the correct hashes, and in 2014 OpenBSD fixed an error with passwords longer than 255 bytes and created $2b$. Today libraries treat all three as equivalent: a $2y$ hash from Laravel validates in Node, and a $2a$ from Spring validates in Python. This page checks all three.

Test users in seeds and migrations

Generate the hash here and store the ready value in the seed instead of calling the library on every run. That keeps the seed deterministic and fast. Keep the plain-text password only in the test environment's documentation, never in the production repository. And check the column size: the hash has 60 characters, and VARCHAR(255) avoids trouble if the algorithm changes later.

Frequently asked questions about bcrypt

Cost, prefixes, the 72-byte limit and what to check when a login fails.