Bcrypt Generator

Generate and verify bcrypt test hashes locally in your browser with an adjustable cost factor from 4 to 16. Inspect the encoded version, cost, salt, and checksum.

Loading...
Bcrypt is a one-way password hashing function with an embedded salt and an exponential cost factor. This browser tool accepts a test password and cost from 4 to 16, then outputs the complete encoded hash; the Verify tab checks a candidate password with the parameters stored in that hash. OWASP treats bcrypt as a legacy-compatible choice and says new systems should prefer Argon2id when available. A production cost must be benchmarked on production-like hardware under expected concurrency; this page cannot select it for you. Bcrypt commonly has a 72-byte input limit, so test your library's exact behavior. Processing occurs in this browser, but do not paste a real production password into any general-purpose page. Read the bcrypt engineering guide and hash definition.
  1. Enter your password in the input field
  2. Choose a cost factor for the test; benchmark the production value in the target service instead of copying this setting
  3. Click 'Generate Hash' to create a bcrypt hash
  4. Copy the generated hash for storage in your database
  5. Use the Verify tab to check if a password matches a hash

Is bcrypt hashing the same as encryption?

No. Encryption is reversible with a key; bcrypt is a one-way password verification function. Store the complete encoded hash and call the library's compare operation. Do not design a workflow that needs to recover the original password.

Why does the same password produce a different bcrypt hash?

A maintained bcrypt library generates a new random 128-bit salt for each hash. The salt is encoded in the result, so different hashes can verify the same password. Compare a candidate with the stored hash; never compare two newly generated hash strings.

What bcrypt cost factor should I use?

There is no universal value. OWASP's current legacy guidance says the work factor should be at least 10, but the final setting must be measured with the selected library on production-like hardware under expected login concurrency. Choose the highest value that meets latency and availability budgets, then rehash after successful login when policy increases.

What is bcrypt's 72-byte password boundary?

Many bcrypt implementations use only the first 72 input bytes; multibyte UTF-8 characters can reach that boundary before 72 characters. Define and test a byte-length policy and never silently truncate. Any pre-hash construction must be explicitly designed, versioned, and reviewed.

How is a password verified against a bcrypt hash?

The verifier reads the version, cost, and salt from the stored 60-character hash, applies bcrypt to the candidate, and compares the checksum using the library's verification API. Add rate limits, secure transport, account controls, and breach response around this operation.