Skip to content

Bcrypt Generator & Checker

Generate a bcrypt password hash at any cost factor, or check a password against one.

Runs in your browser. Never paste a real production hash into any web tool.

Each step doubles the work. 10–12 is the usual production range.

Why does bcrypt produce a different hash every time?

Because a fresh random salt is generated for each hash and stored inside it, in the form $2b$cost$saltdigest. That is why identical passwords never share a hash, and why you must verify with a compare function rather than string equality. The cost is a power of two: cost 10 means 1,024 rounds.

Understanding your result

Two properties make bcrypt suitable for passwords where SHA-256 and MD5 are not. First, it is deliberately slow and the cost is adjustable, so you can keep raising it as hardware improves — general-purpose hashes are fast by design, which is exactly what an attacker wants. Second, it salts automatically and stores the salt inside the hash, which defeats precomputed rainbow tables and means two users with the same password get different hashes. This is also why you must never compare hashes with string equality: the same password produces a different hash every time, so verification has to re-run the computation using the salt embedded in the stored value.

Formula and method

A bcrypt hash is written as $2b$cost$saltdigest. The cost is a power of two: cost 10 means 2^10 = 1,024 rounds of the expensive key-setup step. The 22-character salt and the cost are stored inside the hash, which is how verification can repeat the exact computation later.

Assumptions and limitations

Bcrypt is deliberately slow, so high cost factors take seconds in a browser; this tool caps the cost at 14 for that reason. It is intended for learning and testing — generate real production hashes on your server, in your application code. Never paste a live password or a hash from a production database into any web tool, including this one, and note that bcrypt silently ignores anything past the first 72 bytes of a password.

Worked example

Hashing a password at cost 10 produces a 60-character string beginning $2b$10$, containing a fresh random salt. Hash the same password again and the result differs completely, because the salt is new — yet both verify correctly.

How to use this tool

  1. Choose whether to generate a hash or check one.
  2. Enter the password.
  3. Pick a cost factor, or paste the hash you want to check against.
  4. Copy the resulting hash, or read the match verdict.

Common mistakes to avoid

  • Comparing hashes with == instead of a verify function.
  • Adding your own salt — bcrypt already generates and stores one.
  • Using a cost factor below 10, which is too fast to be protective today.
  • Assuming passwords longer than 72 bytes are fully used; they are truncated.

About the Bcrypt Generator & Checker

This tool generates bcrypt password hashes at a cost factor you choose, and verifies a password against an existing hash. It shows the version, cost and salt encoded inside the hash, and how many rounds that cost represents.

Who should use this tool

Developers implementing authentication, students learning password storage and anyone testing a login system.

Benefits

  • Both directions — generate and verify — in one tool.
  • Breaks the hash down into version, cost and salt.
  • Warns when a password exceeds bcrypt’s silent 72-byte limit.
  • Runs locally, so nothing is transmitted.

Practical use cases

  • Creating a test hash to seed a development database.
  • Checking that your login code verifies hashes correctly.
  • Learning how salting and cost factors work.
  • Inspecting the cost factor an existing hash was created with.

Explore all Security and Privacy tools

Frequently asked questions

Why does the same password give a different hash each time?

Because a fresh random salt is generated for every hash. That is intentional and correct — it is why identical passwords do not produce identical database entries.

What cost factor should I use?

Between 10 and 12 for most applications. Aim for roughly 250ms per hash on your production hardware, and raise it over time as machines get faster.

Is bcrypt better than SHA-256 for passwords?

Yes. SHA-256 is fast by design, which lets attackers try billions of guesses per second. Bcrypt is deliberately slow and adjustable, which is what password storage needs.

Does bcrypt really ignore long passwords?

It uses only the first 72 bytes and silently discards the rest. Long passphrases are still fine, but be aware the tail contributes nothing.

Should I generate production hashes here?

No. Generate them in your application on the server. Use this for learning and testing, and never paste a real password or production hash into a web page.

Share this tool

Free to use — copy the link, share it anywhere, or add the tool to your own website.

Embed this tool on your site (free)

Copy this code and paste it into any web page — it stays free and always up to date: