TextyConverterbeta
⌘K

Bcrypt Hash

Hash a password with bcrypt — the slow, salted, password-hashing standard. Or verify a password against an existing hash.

(4–16, higher = slower)

About Bcrypt Hash

Bcrypt is a password-hashing function designed in 1999 that intentionally runs slowly to make brute-force attacks expensive. Each hash is salted (so identical passwords produce different hashes) and parameterized by a 'cost factor' that controls how slow the function is. Bcrypt is one of the three recommended modern password hashing schemes (alongside scrypt and Argon2).

When to use it

  • Hashing a password for storage in a database
  • Verifying a user-supplied password against a stored bcrypt hash
  • Testing how slow a given cost factor is on your hardware
  • Producing test bcrypt hashes for unit-test fixtures

How it works

In encode mode: a 16-byte random salt is generated, combined with your password, and hashed via bcrypt at the configured cost factor. The output is the standard $2b$... encoded form that captures the salt, cost, and digest in one string. In verify mode: the supplied hash is parsed for its salt and cost, the password is hashed under those same parameters, and the result is compared.

Examples

Re-running with the same password produces a different hash due to the random salt
password=secret, cost=10
$2b$10$abc...xyz (60 chars total)

Frequently asked questions

What cost factor should I use?
Tune it to your hardware: aim for the slowest your auth endpoint can tolerate (typically 0.1–0.5 seconds per hash). Common values today are 10–14. Higher = slower = more resistant to brute force.
Is bcrypt still recommended?
Yes. OWASP lists it among the three acceptable modern password hashing schemes (along with scrypt and Argon2). Argon2id is newer and arguably stronger; bcrypt is fine for most projects.
Why is each hash different?
The salt is randomly generated each time. The hash encodes the salt so verification still works — identical passwords produce different hashes, which means an attacker who steals your database can't tell which users share a password.
Is verification constant-time?
The library uses constant-time comparison internally, so verification doesn't leak timing information about how close the password was to correct.

Related tools