Bcrypt Generator & Verifier

Hash passwords with bcrypt and verify passwords against existing hashes. Processing done server-side with PHP's password_hash().

Password
Cost Factor: 12
Higher cost = slower hashing = harder to brute-force. Cost 12 is the recommended default.

Frequently Asked Questions

Bcrypt is intentionally slow, making brute-force and dictionary attacks extremely expensive. It includes a random 128-bit salt automatically, so identical passwords produce different hashes. The cost factor lets you increase work as hardware gets faster. This is why every major security framework recommends bcrypt (or Argon2) over MD5, SHA-1, or other fast hashes for passwords.
The cost factor (also called the "work factor") is the log₂ of the number of iterations. Cost 12 = 2¹² = 4,096 rounds. Each increment doubles the computation time. OWASP recommends a minimum cost of 10, and at least 12 for new applications. Tune it so hashing takes ~250ms–1s on your production server.
Argon2id is the current OWASP and NIST recommendation for new systems — it won the 2015 Password Hashing Competition and is resistant to both GPU and side-channel attacks. scrypt is memory-hard, making it resistant to GPU brute-force. bcrypt is CPU-intensive but not memory-hard. If you're building a new system, prefer Argon2id. If your system already uses bcrypt with a good cost factor, it remains secure.
Bcrypt is a one-way hash — it cannot be decrypted. Verification works by re-hashing the input password using the same salt embedded in the stored hash, then comparing the results. The salt is embedded in the hash string (the 22 characters after the cost factor). In PHP: password_verify($password, $hash) does this automatically. Never compare bcrypt hashes with === — always use the library's built-in constant-time verify function to prevent timing attacks.
Yes. Bcrypt truncates input at 72 bytes — any characters beyond that are silently ignored. For most passwords this is not a practical issue, but for extremely long passphrases it matters. Mitigation: pre-hash the password with SHA-256 (as raw binary, not hex) before passing to bcrypt — this gives you effectively unlimited password length while keeping bcrypt's salting and slowness. Some frameworks (like Laravel 10) implement this pre-hashing automatically.
Encryption is reversible — if the decryption key is ever leaked, all stored passwords are immediately exposed. Hashing is one-way — there is no key to leak. Even if your entire database is stolen, an attacker must brute-force each hash individually. Passwords should never need to be decrypted — the correct model is: user provides password → server re-hashes it → compare to stored hash.
A timing attack exploits the fact that string comparison functions (===, strcmp) return early as soon as they find a mismatch — the comparison takes measurably less time for incorrect values that differ at the first character. By measuring thousands of response times, an attacker can statistically determine correct bytes one by one. PHP's password_verify() and hash_equals() use constant-time comparison — never use === to compare hashes or tokens.
To hash: $hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]); — store the resulting 60-character string in your database. To verify: if (password_verify($input, $storedHash)) { /* authenticated */ }. To check if rehashing is needed: if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12])) { $hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]); }.
A pepper is a secret value stored in application config (not the database) that is HMAC'd with the password before hashing. If the database is stolen but the application server is not, the attacker cannot crack the hashes without the pepper. Implementation: $peppered = hash_hmac('sha256', $password, $PEPPER); $hash = password_hash($peppered, PASSWORD_BCRYPT);. OWASP considers peppers a reasonable additional control for high-security applications.
$2a$ is the original bcrypt format with a bug in some implementations regarding 8-bit characters. $2b$ is the corrected format (fixed in OpenBSD). $2y$ is PHP-specific and equivalent to $2b$ — introduced before the official fix to signal the corrected behavior. For new hashes PHP uses $2y$. All three verify correctly against each other in modern implementations.

About This Bcrypt Generator

This free bcrypt generator hashes a password using the bcrypt algorithm with a configurable cost factor. Enter a password and select a cost to generate a hash suitable for storing in a database.

When to use this tool

  • Generating test bcrypt hashes during development
  • Verifying that your application stores passwords correctly
  • Understanding how cost factor affects computation time
  • Creating hashes for seeding a user database

Related Developer Tools

Hash Generator Random String Password Generator JWT Decoder

Related Articles

In-depth guides and technical articles.

View all →
Your Password Hash Is a Denial-of-Service Amplifier
Developer Sep 21, 2026
Your Password Hash Is a Denial-of-Service Amplifier
A deliberately slow hash makes your login endpoint a denial-of-service amplifier. Rate limiting before hashing, dummy hashes for unknown users, and async execution fix it.
Reading a bcrypt Hash: What $2b$12$ Means and Where the Salt Is
Developer Aug 25, 2026
Reading a bcrypt Hash: What $2b$12$ Means and Where the Salt Is
A bcrypt hash is four fields packed into one string. Learn to read the version prefix, cost, embedded salt and digest — and why the salt is stored in plain sight.
Argon2id Won the Password Hashing Competition — Here's Why Memory-Hardness Matters and When to Migrate From bcrypt
Developer Jul 1, 2026
Argon2id Won the Password Hashing Competition — Here's Why Memory-Hardness Matters and When to Migrate From bcrypt
Argon2id won the Password Hashing Competition and is now OWASP's recommended algorithm — but its three variants (Argon2i, Argon2d, Argon2id) have different security properties, and Argon2d is specifically not suitable for password hashing despite being in the family. Here's memory-hardness and why it defeats GPU parallelism, the correct Argon2id parameters (19 MB memory, 2 iterations), when to migrate from bcrypt, and the pepper pattern for additional server-side secret protection.
bcrypt Work Factors Double With Each Increment — Here's How to Choose the Right One and Upgrade Existing Hashes
Developer Jun 22, 2026
bcrypt Work Factors Double With Each Increment — Here's How to Choose the Right One and Upgrade Existing Hashes
bcrypt's work factor doubles hashing time for every increment — work factor 10 is ~100ms, work factor 12 is ~400ms, work factor 14 is ~1.6 seconds. This exponential relationship is the design feature, not a side effect: when hardware gets faster, incrementing the work factor by 1 restores the original time cost. Here's how to choose the right factor, the opportunistic re-hash strategy for upgrading existing hashes without forcing logout, and how to read the work factor from a stored bcrypt hash string.
Bcrypt's 72-Byte Limit: Why Two Different Passwords Can Hash to the Same Value
Developer Jun 13, 2026
Bcrypt's 72-Byte Limit: Why Two Different Passwords Can Hash to the Same Value
Bcrypt silently truncates input at 72 bytes — meaning two passwords sharing the same first 72 bytes but differing afterward produce the identical hash. Here's why 72 specifically, how multi-byte Unicode characters (emoji especially) reach this limit far sooner than "72 characters" suggests, why pre-hashing with SHA-256 is a common mitigation, and why this isn't actually a meaningful security concern for typical passwords.