Bcrypt Hash Generator & Verifier - Client-Side Password Hashing

How to use this tool

1. Enter a password and choose a cost factor; the default is 12 and higher values take longer.
2. Click "Hash Password" to generate a bcrypt hash, or cancel the worker while it runs.
3. Inspect a complete bcrypt hash to view its version, cost, salt, and digest.
4. To verify, paste a hash and enter its password, then click "Verify".

How Bcrypt Works

Bcrypt is based on the Blowfish block cipher. During hashing, a random 16-byte salt is generated and the Expensive Key Schedule (EKS) Blowfish setup is run for 2^cost key-schedule iterations. The "OrpheanBeholderScryDoubt" magic string is then encrypted 64 times; bcrypt encodes the result as a 31-character digest alongside the salt and cost.

Choosing a Cost Factor

This tool starts at cost 12, which performs 2¹² (4,096) key-schedule iterations. Higher costs take about twice as long for each step, but elapsed time depends on the device running the tool. Use the displayed browser timing to compare settings, then benchmark separately on the server that will handle real logins; browser timing is not a substitute for measuring your production system.

Cost factor benchmark

The table below shows approximate hashing times on a modern server CPU (single-threaded). Actual times vary by hardware and implementation. The table is a rough comparison only; benchmark on your own server before choosing a value for production.

Password storage security

Never store plaintext passwords. When a user sets a password, bcrypt hashes it with a random salt before storing. Each bcrypt hash is unique even for identical passwords, so attackers cannot use a single precomputed table (rainbow table) to crack multiple accounts at once. The one-way nature of the hash means the original password cannot be retrieved from the stored value.

Bcrypt processes at most 72 password bytes, not 72 visible characters. This tool counts UTF-8 bytes and warns when an input is longer; bytes beyond that limit are ignored by bcrypt. Two passwords that share their first 72 bytes therefore produce the same bcrypt input, even when their remaining characters differ. Check this limit when debugging passwords that include emoji or other multi-byte characters.

Generated hashes use the $2b$ prefix. The inspector and verifier also accept $2a$ and $2y$ prefixes, commonly seen in existing application data. A few older $2a$ implementations handled non-ASCII password bytes differently; if such a legacy hash fails, confirm it with the library that created it. For new systems, consider Argon2id where your platform supports it, and use the same password-hashing library and settings in production.

Modern alternatives worth considering:

• Argon2id (winner of the Password Hashing Competition): memory-hard; the current best-practice recommendation for new systems.
• scrypt: also memory-hard; widely supported; used by Litecoin and other systems.
• PBKDF2: FIPS-approved; suitable when regulatory compliance requires it.

Bcrypt hash format

A bcrypt output string looks like: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lfkpwkE