Security Tools

Bcrypt Hash Generator & Checker

Create bcrypt hashes with an adjustable cost factor, verify a password against an existing hash for login debugging, and inspect the version, cost and salt of any bcrypt hash.

Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Passwords are never included in share links, only the hash and settings.

Generate Hash

0 / 72 bytes

10
481215

Bcrypt Hash

Check Password Against Hash

Hash Anatomy
Paste a bcrypt hash above to see its parts.

About bcrypt password hashing

Bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazières, based on the Blowfish cipher. It is deliberately slow and includes a random 128-bit salt in every hash, so identical passwords produce different hashes and precomputed rainbow tables are useless. It remains the default password hasher in Laravel, Ruby on Rails, Spring Security and many other frameworks.

A bcrypt hash such as $2y$10$N9qo8uLOickgx2ZMRZoMye... is self-describing: the version prefix, the two-digit cost, a 22-character salt and a 31-character checksum, all in bcrypt's own Base64 alphabet. Because the salt and cost are stored in the hash, a verifier only needs the password and the hash string.

The cost factor is a base-2 logarithm: cost 10 means 210 = 1,024 rounds of key expansion, and every increment doubles the time. OWASP recommends a minimum of 10; pick the highest value that keeps login acceptably fast on your server, typically around 100–300 ms. The prefixes $2a$, $2b$ and $2y$ produce the same result for normal passwords. $2y$ is what PHP emits and $2b$ is the current OpenBSD revision; this checker accepts all three.

Bcrypt only uses the first 72 bytes of a password, so very long passphrases (or multi-byte characters) beyond that limit are silently truncated. All hashing on this page runs in your browser with the bcrypt.js library. For production systems, always hash on the server with a native implementation, and never reuse real user passwords in online tools.

When to use the verifier: debugging a login that fails after a database restore or migration, checking that users imported from another framework still authenticate, or confirming that seed data in staging uses the expected cost factor. Use synthetic test passwords, which you can create with the password generator.

Bcrypt is only for passwords. For file checksums use the hash generator (SHA-256), and for API or webhook signatures use the HMAC generator. Bcrypt is far too slow for those jobs and its random salt makes the output different every time.

Reference Guide

Anatomy of $2y$10$PP5S4FAfRBG//qRJmqUImeORLzY9nW6u2agnMNCJmKVErwl0Tya1G (60 characters):

SegmentExampleMeaning
Version$2y$Bcrypt variant: $2a$, $2b$ or $2y$ (PHP)
Cost10Work factor: 210 = 1,024 key expansion rounds
SaltPP5S4FAfRBG//qRJmqUIme22 characters, 128-bit random salt stored in the hash
HashORLzY9nW6u2agnMNCJmKVErwl0Tya1G31 characters, the derived password hash

How the cost factor scales (each step doubles the work):

CostRoundsRelative timeTypical use
4161/64×Unit tests only (fast, insecure)
101,0241×OWASP minimum; a common library default
124,0964×Newer framework default; good choice for web logins
1416,38416×High-security accounts; slow under login load

Recommended: cost 10–12 for web apps. Increase it over time and rehash the password on the user's next successful login.

Example input

password123
$2y$10$PP5S4FAfRBG//qRJmqUImeORLzY9nW6u2agnMNCJmKVErwl0Tya1G

This sample loads automatically when you open the tool. Use Load Sample to bring it back.

Frequently Asked Questions

Choose the highest cost your servers can handle while keeping login fast, typically 10 to 12. Each step doubles the work, so cost 12 is four times slower than cost 10.

bcrypt generates a random salt for every hash and stores it inside the result, so the same password produces a different hash each time. Verification still works because the salt is read back from the hash.

They are bcrypt version prefixes. $2y$ is used by PHP and $2b$ by newer OpenBSD-derived libraries; both fix old bugs in $2a$. Hashes are compatible for normal passwords.

Yes. bcrypt only uses the first 72 bytes of the password, so longer passwords are truncated.