Bcrypt Generator & Checker.

Because bcrypt generates a fresh random salt for every hash and embeds it in the output. That is a feature: two users with the same password get completely different hashes, and precomputed rainbow tables become useless. Verification still works, because the salt is read back out of the hash itself.

The cost (work factor) is an exponent: cost 12 means 2¹² = 4,096 internal rounds. Each +1 doubles the computation time — for you and for an attacker. Choose the highest cost your login latency budget allows; 10–12 is the common production range in 2026.

No — bcrypt is a one-way function, there is nothing to decrypt. The only way to recover a password is to guess candidates and hash each one, which is exactly what the cost factor makes expensive. A strong, unique password stays out of reach even for well-funded attackers.

They are format version prefixes: $2b$ is the current standard, $2y$ comes from PHP's fix of an old bug, $2a$ is the original. Modern libraries verify all of them interchangeably. The two digits after it are the cost factor, followed by 22 characters of salt and 31 of hash.

The Blowfish cipher inside bcrypt only keys on the first 72 bytes of input — anything longer is silently ignored by most implementations. For normal passwords that is irrelevant; for machine-generated secrets or passphrases, either keep them under 72 bytes or pre-hash them (carefully) before bcrypt.

For new systems, Argon2id is the current recommendation (OWASP) because it also hardens against GPU attacks with configurable memory cost. bcrypt remains a solid, battle-tested choice with excellent library support — if your stack already uses it with a sensible cost factor, there is no urgent need to migrate.

Hashing and verification run entirely in your browser via a JavaScript bcrypt implementation — nothing is transmitted, stored, or logged. Still, prefer test passwords: this tool is for development and debugging, not for handling your real credentials.