bcrypt Online - Password Hashing

bcrypt is a password hashing function designed by Niels Provos and David Mazières and published at USENIX in 1999. It is based on the Blowfish cipher and was built for password storage, not general file checksums: each password guess is intentionally slow, uses a unique salt, and can be made more expensive by raising the cost factor.

A bcrypt password hash is a self-contained string such as $2b$12$.... It stores the algorithm version, the cost, a 128-bit salt encoded in bcrypt's custom Base64 alphabet, and the final hash. Because the salt and cost are embedded, a database normally stores one bcrypt string per user password and the verification library can reproduce the same settings later.

Use this bcrypt online tool when you need a bcrypt hash generator for documentation, test fixtures, migration checks, or quick experiments with cost factors. Use the Verify mode when you have an existing bcrypt hash and want to check whether a candidate password matches it.

bcrypt's cost factor is an exponent: cost 10 means roughly 2^10 units of internal work, cost 12 means roughly 2^12, and each increase by 1 doubles the work needed for both attackers and legitimate logins. A conservative bcrypt baseline is a work factor of 10 or more when Argon2id or scrypt are not available, and the practical value should be benchmarked on the server that will handle real authentication.

This tool exposes cost values from 4 to 31, with 12 as the default. Lower values are useful only for demonstrations and fast tests; production systems should choose the highest cost that still keeps login verification responsive under load. As a rule of thumb, aim for a noticeable but acceptable delay, monitor sign-in latency, and raise the cost over time as hardware improves.

The cost is stored inside each bcrypt hash, so old hashes can still be verified after you change the policy. A common upgrade pattern is to verify the old hash during login, then rehash the same password with the newer cost and replace the stored value after successful authentication.

In Generate mode, enter a password or passphrase, choose the cost factor, and run the calculation. The browser creates a random salt automatically and returns a bcrypt string beginning with $2b$. Running the same password twice should produce different hashes because the salt is different every time.

In Verify mode, paste the candidate password as input and paste the stored bcrypt hash into the verification field. The tool reads the cost and salt from the stored hash, runs bcrypt with the same parameters, and returns whether the password matches. It recognizes modern bcrypt strings beginning with $2a$, $2b$, or $2y$.

Everything runs client-side with the JavaScript bcrypt implementation used by the page. The password and hash are not sent to the server, which makes the tool convenient for examples and debugging. For real user accounts, still hash and verify passwords inside your application backend using a maintained server-side library, rate limiting, audit logging, and secure deployment practices.

Developers usually need bcrypt for a few practical tasks: creating a bcrypt password hash for a test user, verifying whether a password matches a stored hash, comparing bcrypt cost factors, checking the meaning of a $2b$ hash string, or planning a migration from legacy password storage.

This page covers common bcrypt generator and verifier questions: how to generate a bcrypt hash online, how to verify a bcrypt hash, what a bcrypt salt is, how the cost factor works, how bcrypt compares with Argon2, and why the 72-byte password limit matters. The important production pattern is simple: generate a unique salted hash, store the full bcrypt string, verify with a maintained library function, and rehash when the stored cost becomes weaker than your current policy.