bcrypt & argon2 Checker

Hashes a password with bcrypt at a chosen cost and checks a password against an existing bcrypt hash. Detects argon2 but does not compute it.

Hashes a password with bcrypt, or checks a password against an existing `$2a$`/`$2b$`/`$2y$` hash. The implementation is OpenBSD’s `$2b$` verified against the published Openwall crypt_blowfish vectors, and it runs in a worker in this tab.

🔒 Runs entirely in your browserbcryptargon2passwordhash

Mode

Password

Processed in this tab only; nothing is transmitted.

Cost

1,024 rounds — the long-standing default.

This is bcrypt as OpenBSD defines $2b$ , verified against the published Openwall crypt_blowfish test vectors, running entirely in this tab. Only the first 72 bytes of a password count — that is bcrypt, not a bug here. $2x$ hashes (made by a pre-2011 crypt_blowfish bug) are refused, and argon2 is not implemented.

How to use it

Pick hash or verify
Hashing needs a cost; verifying reads the cost out of the hash you paste, because it is stored in the string.
Choose a cost you can afford
Each step doubles the work. 10 was the default for years, 12 is a solid current choice, and 14 takes a few visible seconds in a browser — which is the point: it takes an attacker that long too.
Read the verdict
Match or no match. Everything happens in the tab, so a production hash pasted here is not travelling anywhere.

Common questions

Why is argon2 refused rather than supported?

Because a trustworthy argon2 in a browser means shipping a WebAssembly build this project cannot audit line by line. bcrypt is implemented here in code you can read, checked against published vectors. Refusing an argon2 hash is more honest than a plausible-looking answer from a black box.

Why does my long password verify against the wrong hash?

bcrypt only reads the first 72 bytes. Two passwords sharing their first 72 bytes are the same password to it — that is bcrypt itself, not this implementation. It matters for a passphrase, and it is one reason people move to argon2.

Why does hashing the same password twice give different strings?

Because each run generates a fresh 16-byte salt, and the salt travels inside the hash. Both strings verify the same password. A password hash that is the same every time is a password hash without a salt, which is the thing rainbow tables were built for.

Are $2a$, $2b$ and $2y$ different?

Not for any password of 72 bytes or less, which is all of them. The prefixes record which historical bug a hash was made before or after. `$2x$` is the exception — it marks hashes made by a pre-2011 crypt_blowfish bug, and those are refused here.