Bcrypt Generator

Bcrypt Generator

Free bcrypt hash generator and verifier — 100% client-side. Real-time cost benchmark, hash parser, code snippets for Node.js, Python, PHP, Go. No signup.

Updated June 2026

Zero Network Activity — 100% Browser-side
CLIENT-SIDE SECURE
12
4 — testing Default is 12 (OWASP). Higher = more secure but slower. 18 — very slow

Local Benchmark

Processing time on your current hardware

Cost 8
—
Cost 10
—
Cost 12
—
Cost 14
—

Implementation Snippets

const bcrypt = require('bcryptjs');
const SALT_ROUNDS = 12; // OWASP recommended

async function hashPassword(plaintext) {
  return await bcrypt.hash(plaintext, SALT_ROUNDS);
}

async function verifyPassword(plaintext, hash) {
  return await bcrypt.compare(plaintext, hash);
}

const hash = await hashPassword('user_password');
// '$2b$12$...' (60 chars, always different due to random salt)

const isValid = await verifyPassword('user_password', hash);
// true

Bcrypt Hash Generator Online — Free, 100% Client-Side, No Signup

Generate and verify bcrypt hashes entirely in your browser — no server involved, no data logged. Every hash is computed locally using bcryptjs, a pure JavaScript implementation of bcrypt. Open DevTools, watch the Network tab stay empty, and confirm for yourself: nothing leaves your machine.

This tool goes beyond the basic hash-and-verify flow. Measure the real hashing time on your hardware for each cost factor, parse any existing bcrypt hash to understand its structure, and copy ready-to-run code for eight programming languages — all in one place.

How to Use the Bcrypt Generator

Getting a bcrypt hash from a password takes under five seconds:

  1. Paste or type your password in the Input Password field — the "CLIENT-SIDE SECURE" badge confirms no network request will be made.
  2. Adjust the cost factor with the slider (4–18). Cost 12 is the OWASP-recommended default; higher values increase security but also increase hash time.
  3. Click "Generate Bcrypt Hash" — the hash appears instantly below the button, along with the exact time it took on your current device.
  4. Copy the hash with the copy button or press Shift+Enter from outside the input fields.

To verify a password against an existing hash, switch to the Verify Hash tab, enter both values, and click "Verify Match" — you'll see a green checkmark or red X within milliseconds.

Bcrypt Hash Examples

Bcrypt always produces a 60-character string. Because of the random salt, the same password hashed twice will always produce a different hash — but both will verify correctly against the original password.

Example — cost factor 12 (OWASP default):

Input:  mysecretpassword
Output: $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa

Example — cost factor 14 (high security):

Input:  mysecretpassword
Output: $2b$14$xQ3sZk0y1K8cHjpLm9D.nuR2Gt5vXwYoAbEFqMNCdI6OkPgT7VhWs

Edge case — same password, different hash:

Input:  mysecretpassword  (hashed twice at cost 12)
Hash 1: $2b$12$nOUIs5kJ7naTuTFkBy1veu...
Hash 2: $2b$12$aBcDeFgHiJkLmNoPqRsTuv...  ← different salt, both are valid

Edge case — the 72-byte truncation limit:

Input:  [a string of 72 'a' characters]
Input2: [a string of 73+ 'a' characters]
Result: both produce hashes that match each other — bytes beyond 72 are silently ignored

Bcrypt Hash Format — What Each Part Means

Every bcrypt hash has exactly the same structure. For $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa:

Segment Value Meaning
Version $2b$ Algorithm version — always use $2b$ for new implementations
Cost 12 2¹² = 4,096 iterations
Salt nOUIs5kJ7naTuTFkBy1veu 22 chars, base64-encoded 128-bit random salt
Hash K0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa 31 chars, the actual checksum

The version prefixes: $2a$ is the original spec with an edge-case bug for high-byte characters; $2b$ is the corrected standard; $2y$ is PHP's equivalent to $2b$. Always use $2b$ for new code.

What Is Bcrypt and Why Does It Matter?

Bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, built on the Blowfish cipher. Unlike MD5 or SHA-256 — which are fast general-purpose functions — bcrypt is intentionally slow. Its cost factor is adjustable, which means you can increase the computational work required as hardware gets faster, keeping brute-force attacks economically infeasible over time.

Crucially, bcrypt automatically generates and embeds a unique random salt for every hash. This prevents rainbow table attacks, where attackers use precomputed lookup tables to reverse common hashes. Even if two users have identical passwords, their bcrypt hashes will differ.

Common Use Cases

  • User authentication systems: Hash user passwords before storing them in a database. On login, bcrypt.compare() runs the same algorithm with the stored salt and confirms a match in constant time, preventing timing attacks.
  • Migration from weaker algorithms: Progressively re-hash passwords from MD5/SHA-1 to bcrypt. On successful login with the old hash, verify the password and immediately replace the stored hash with a bcrypt one.
  • Cost factor calibration: Run the local benchmark on your production server's hardware to find the highest cost factor that keeps login latency under your UX threshold (typically 300ms–1s).
  • Security audits: Paste an existing hash into the parser to verify it uses $2b$, confirm the cost factor meets OWASP minimums, and check the salt and hash lengths are correct.
  • Learning and teaching: The hash structure decomposition shows exactly how bcrypt encodes version, cost, salt, and output — useful for security courses and onboarding new engineers.

Common Mistakes with Bcrypt

  • Using cost 4–8 in production: These values complete in under 1ms and offer no meaningful brute-force resistance. Cost 4 exists only for unit tests where speed matters. Use cost 10 as an absolute minimum, cost 12 as the default.
  • Hashing already-hashed passwords: Running bcrypt on a bcrypt hash produces a double-encoded string that can never be verified. Always hash the original plaintext password only.
  • Ignoring the 72-byte limit: Bcrypt silently truncates input at 72 bytes. A password of "a" × 72 and "a" × 100 produce equivalent hashes. If your application allows passwords longer than 72 ASCII characters, pre-hash with SHA-256 before passing to bcrypt — or switch to Argon2id, which has no such limit.
  • Storing the salt separately: Bcrypt embeds the salt inside the 60-character hash string. You do not need a separate salt column. Store only the full bcrypt hash — the library extracts the salt automatically during verification.

Frequently Asked Questions

What cost factor should I use for bcrypt?

OWASP recommends cost factor 12 as a starting point, targeting approximately 250ms per hash on modern hardware. The right value depends on your specific server — use the local benchmark on this page to measure actual timing, then choose the highest factor that keeps your authentication latency under your UX threshold (typically 300ms–1s). Raise the cost factor as hardware improves every few years.

Can a bcrypt hash be reversed or decrypted?

No. Bcrypt is a one-way function — there is no mathematical method to derive the original password from a hash. The only approach is brute force: guess passwords, hash each one with the stored salt, and compare. The deliberately high iteration count makes this computationally expensive. A cost 12 hash takes ~250ms per attempt on modern hardware; guessing a billion passwords would take over 8,000 years on a single machine.

What is the difference between $2a$ and $2b$ bcrypt?

$2a$ is the original bcrypt spec from 1999. Some implementations had an edge-case bug when hashing passwords containing characters with the high bit set (bytes above 127). $2b$ corrects that bug and is the current standard. $2y$ is a PHP-specific variant mathematically equivalent to $2b$. For any new implementation, use $2b$. If you have existing $2a$ hashes, they continue to work correctly in most cases — migration is only needed if you have evidence of the bug affecting your users.

Does bcrypt support passwords longer than 72 characters?

Bcrypt processes only the first 72 bytes of any input. Characters beyond 72 bytes are silently ignored, so "a" × 72 and "a" × 100 hash to equivalent values and are mutually verifiable. If users could create passwords longer than approximately 60–70 characters, this is a security concern: consider pre-hashing the password with SHA-256 before passing to bcrypt, or switching to Argon2id which has no length limit.

Should I use bcrypt or Argon2id for a new project?

OWASP now recommends Argon2id as the first choice for new systems — it is memory-hard (more resistant to GPU and ASIC attacks), has no password length limit, and won the Password Hashing Competition in 2015. Bcrypt remains a solid, battle-tested choice for systems already using it, with cost factor 12 or higher. If you are starting from scratch and your language/framework provides good Argon2id support, prefer Argon2id. For legacy systems, bcrypt at cost ≥ 12 is still acceptable per OWASP.

Resources

Related article

Salt, Pepper, Bcrypt and Argon2id: How to Actually Protect Passwords

Related Tools