Bcrypt Hash Generator & Checker

Hash a password with bcrypt at an adjustable cost factor, or verify a password against a hash.

Updated: June 26, 2026

Password

Cost factor (rounds)10

Higher = slower & stronger. 10–12 is typical for production.

What is bcrypt?

Bcrypt is a password-hashing function designed specifically for storing passwords safely. Unlike fast hashes such as SHA-256, bcrypt is deliberately slow and includes a built-in random salt, so every hash of the same password is different and attackers can't use precomputed lookup ("rainbow") tables. This tool lets you generate a bcrypt hash or check a password against an existing hash — all in your browser.

The cost factor

The cost factor (also called work factor or rounds) controls how slow the hash is: each increment doubles the work. A cost of 10 means 2¹⁰ iterations. You want it high enough that hashing takes a meaningful fraction of a second — slowing attackers down — without hurting your own login latency. 10 to 12 is typical for production in 2026; raise it as hardware gets faster. Try moving the slider above and notice how higher costs take visibly longer to compute.

Reading a bcrypt hash

A bcrypt hash looks like $2b$10$N9qo8uLOickgx2ZMRZoMye... and encodes everything needed to verify it later:

$2b$ — the algorithm version identifier.
10$ — the cost factor.
The next 22 characters are the salt; the rest is the hash itself.

Because the salt and cost are stored inside the string, you don't need to track them separately — the verifier reads them straight from the hash.

Verifying a password

The Verify tab takes a plain-text password and a bcrypt hash and tells you whether they match. This is exactly what a login system does: it never "decrypts" the stored hash (bcrypt is one-way) — it re-hashes the supplied password with the same salt and cost embedded in the stored hash, then compares. Use this to debug authentication or confirm a hash was generated correctly.

Important: don't hash production passwords in a browser tool

This page is great for learning, testing and debugging. But in a real application you should hash passwords on your server, inside your auth framework, so plain-text passwords never travel further than they must. Treat this tool as a sandbox. And never store passwords with a fast hash like MD5 or SHA-256 — those are for integrity, not password storage. Bcrypt, scrypt or Argon2 are the right choices.

Frequently asked questions

Why use bcrypt instead of SHA-256 for passwords?

SHA-256 is fast, which helps attackers brute-force leaked hashes billions of times per second. Bcrypt is deliberately slow and salted, making large-scale guessing impractical. Use bcrypt (or scrypt/Argon2) for passwords; use SHA for integrity checks.

What cost factor should I choose?

A cost of 10–12 is typical for production in 2026. Pick the highest value that keeps login time acceptable (well under a second on your server). Increase it over time as hardware speeds up.

Why is the hash different every time for the same password?

Bcrypt generates a random salt for each hash and stores it inside the output. Different salts produce different hashes, which is what defeats rainbow-table attacks. Verification still works because the salt is embedded in the hash.

Can a bcrypt hash be reversed?

No. Bcrypt is a one-way function. Verification works by re-hashing the candidate password with the stored salt and cost, then comparing — never by decrypting the hash.

Authentication infrastructure

If you're building login yourself, consider whether a managed service would be safer:

Managed authentication service Offload password hashing, storage, MFA and breach detection to a provider that keeps up with best practices.
Secrets manager Keep the pepper/keys and database credentials behind your auth system out of source code and config files.