b2KIT

bcrypt Hash Generator & Verifier

Generate bcrypt password hashes with configurable cost factor and verify passwords against existing hashes.

Tested tool guide Tested browser tools Checked August 15, 2026

What bcrypt Hash Generator & Verifier does and how it behaves

Type a password and a cost factor and this tool produces a bcrypt hash in the standard $2a$/$2b$ format, computing it locally with a freshly generated random salt each run. Paste an existing hash alongside a candidate password into the verify panel and it recomputes the hash using the salt embedded in that string to check for a match. The detail people miss most: bcrypt only reads the first 72 bytes of a password, so anything past that point is ignored, and because the salt is regenerated every run, hashing the same password twice on purpose never produces two identical strings - that is expected, not a bug.

How the result is produced

1

Hash format and cost factor

The output is a 60-character string: a version tag ($2a$, $2b$, or $2y$), a two-digit cost between 4 and 31, then a 22-character salt and a 31-character hash, both encoded in bcrypt's own base64-like alphabet. Cost sets the number of key-setup rounds to 2^cost, so raising it by one roughly doubles the time needed to generate or verify a hash.

2

Verification without a stored password

Verify mode never needs the original password saved anywhere: it parses the version, cost, and salt out of the pasted hash, reruns the same Blowfish-based key setup on the candidate password using that salt, and compares the result to the hash portion of the string. A match confirms the password produces that exact hash under those parameters.

Good uses

  • Generating bcrypt hashes to seed a test database or fixture file with realistic password hash values
  • Checking whether a plaintext password someone reports actually matches a hash pulled from a config file or database export
  • Timing hash generation at different cost factors on your own machine before picking a default for a login system

Limits and checks

  • Passwords longer than 72 bytes are silently truncated by the bcrypt algorithm itself, so two inputs that only differ after byte 72 hash identically - this is a property of bcrypt, not a bug in this tool.
  • Two hashes generated from the same password will never be equal, because each run embeds a new random salt; comparing generated hashes by eye or by diff will always show a mismatch even for the same password, so use verify mode instead.
  • High cost factors (mid-teens and up) can take several seconds or more per hash since the work runs in the browser tab itself, which can make batch testing of many passwords impractically slow.

Common questions

Why does hashing the same password twice give two different results?

Because bcrypt embeds a new random salt in every hash it produces, by design - that's what makes precomputed rainbow-table attacks impractical. Both hashes are equally valid for that password. To check whether a password matches a hash, use the verify function rather than comparing hash strings directly.

What cost factor should I use?

There is no single correct number - it depends on your server's hardware and how much login latency you can accept. OWASP's Password Storage Cheat Sheet suggests a bcrypt work factor of at least 10 as a floor, tuned upward as far as your hardware and response-time budget allow, so treat any figure as a starting point to benchmark.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools