🔑 Bcrypt Hash Generator

By Λ · Updated June 9, 2026 · ~3 min read

What this tool does

Generates and verifies bcrypt hashes with zero server involvement: bcrypt.js, a port of the OpenBSD original, does the work locally in this page, so typed passwords stay inside the tab. Each hash includes a random salt and the cost factor in the hash string itself, so verification later only needs the password and the stored hash.

How the two panels work

The Generate panel feeds your password and the slider value (4 through 15, default 12) into genSaltSync, then hashSync. The timing label estimates the delay, doubling with each cost step above 10. The Verify panel runs compareSync and prints MATCH, NO MATCH, or an invalid-format error; clicking a finished hash copies it.

Worked example

Enter hunter2 at cost 12 and press Generate Hash: out comes a 60-character string opening with $2a$12$ followed by 53 characters of encoded salt and digest. A second press yields a different string because the salt changes. Verify either result against hunter2 and it reports MATCH; swap one letter and it flips to NO MATCH.

Anatomy of a bcrypt hash

A bcrypt hash looks like $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW. Breaking it down:

• $2b$: the bcrypt version. 2a is the original; 2b fixed a bug in 2014; 2y is a PHP-specific variant. All are interchangeable for verification.
• 12: the cost factor. The hash takes 2^cost iterations of the Blowfish key schedule. Cost 12 = 4,096 iterations.
• R9h/cIPz0gi.URNNX3kh2O: the salt (22 chars, 16 bytes Base64-ish encoded).
• PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW: the actual hash (31 chars, 24 bytes encoded).

Picking a cost factor in 2026

The cost factor controls how slow the hash is. Slower = harder for an attacker to brute-force, also slower for legitimate logins. The right balance:

• Cost 10: about 100ms on a modest server. The old default. Acceptable for low-stakes applications.
• Cost 12: about 400ms. OWASP 2026 recommended default. Right for most production apps.
• Cost 14: about 1.6s. Right for high-value targets (admin accounts, financial systems).
• Cost 16+: 6+ seconds. Reasonable for offline encrypted backups, not for interactive logins.

The 72-byte limit

Bcrypt silently truncates passwords longer than 72 bytes. This catches developers off-guard regularly. If your users can submit passwords longer than 72 bytes (common with Unicode or passphrases), pre-hash with SHA-256 then bcrypt the digest, or move to Argon2id which has no length limit.

Bcrypt versus Argon2id

Argon2id is the modern recommendation for new code. It is memory-hard (much harder for GPUs to attack in parallel), has no password length limit, and was specifically designed in 2015 to replace bcrypt. Bcrypt remains acceptable for existing deployments and for applications where library availability is limited; almost every language has a maintained bcrypt library.

For the deep version of this comparison, see my blog post on password hashing in 2026.

Edge cases worth knowing

The slider tops out at 15 because JavaScript bcrypt runs slower than native builds; one hash there can hold the tab for several seconds. Never string-compare two hashes to check a password; differing salts guarantee inequality, so use the verifier.

Frequently Asked Questions

Why does the same password give a new hash on every click?

Each run draws a fresh random salt and embeds it in the output; both hashes still verify against that password.

Will hashes made here verify on my backend?

Yes. The page emits standard $2a$ strings that bcrypt libraries for Go, Python, PHP, Node, and Java all accept, and the verifier reads PHP's $2y$ output fine.

Is typing a real password into this page safe?

Hashing stays local; still, test with throwaway strings and let your backend hash real credentials at signup.

Related

For fast-hash use cases (file integrity, content addressing), see the hash generator. For HMAC signatures, see HMAC generator. For TOTP / 2FA, see the TOTP generator.