Bcrypt Generator & Verifier

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

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 by being configurable in time, memory, and parallelism. scrypt is memory-hard (requires significant RAM per computation), making it resistant to GPU brute-force. bcrypt is CPU-intensive but not memory-hard, meaning modern GPUs can parallelise attacks more effectively than against Argon2id. If you're building a new system, prefer Argon2id. If your system already uses bcrypt with a good cost factor, it remains secure — migrating is not urgent.

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 === or string comparison functions — 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. This means a 100-character password and the same password with different characters after position 72 would produce the same hash. 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 (in a breach, by an insider, or through a vulnerability), 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 authentication model is: user provides password → server re-hashes it → compare to stored hash. If you ever need to "recover" a user's password, that's a design flaw; the correct action is a reset flow.

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. Constant-time comparison always takes the same amount of time regardless of where the mismatch occurs, preventing this information leak. PHP's password_verify() and hash_equals() use constant-time comparison. Never use === to compare hashes, tokens, or HMAC values.

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 (after raising the cost factor): if (password_needs_rehash($storedHash, PASSWORD_BCRYPT, ['cost' => 12])) { $newHash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]); /* store new hash */ }. Use PASSWORD_DEFAULT instead of PASSWORD_BCRYPT if you want PHP to automatically upgrade to the strongest algorithm in future versions.

A pepper is a secret value (stored in application config or an HSM, not the database) that is appended to or 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. The downside: if the pepper is lost, all passwords must be reset. Peppers are optional but add a meaningful additional layer of defense. Implementation: $peppered = hash_hmac('sha256', $password, $PEPPER); $hash = password_hash($peppered, PASSWORD_BCRYPT);. OWASP considers peppers a reasonable additional control for high-security applications.

These are bcrypt version identifiers: $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$ — it was 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. If you see $2a$ hashes in an older system, they are still valid and password_verify() handles them correctly.

About This Bcrypt Generator

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

Bcrypt is a password-hashing function designed for security: it is deliberately slow (controlled by the cost factor), includes a random salt in every hash, and produces a different output each time even for the same input — making it resistant to brute-force and rainbow-table attacks.

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

Standards & References

How Bcrypt Hashing Works

Bcrypt is a password-hashing function based on the Blowfish cipher, designed to be computationally expensive by design.

Generate Random Salt

PHP's password_hash() automatically generates a 128-bit (22 Base64-character) cryptographically random salt for every call. You never provide a salt manually — this prevents salt reuse vulnerabilities.

Expand Key Over 2^cost Rounds

The password and salt are fed into the EksBlowfishSetup key schedule, which is repeated 2cost times. At cost 12 that's 4,096 expensive key expansions — far slower than SHA-256 for an attacker.

Embed Metadata in Hash

The 60-character output encodes everything needed to verify: $2y$ (algorithm), 12$ (cost), 22-char salt, and 31-char digest. The salt is embedded, so verification needs only the hash string — never separate storage.

Each call generates a different hash even for the same password, because the salt is random. Use password_verify() — never compare bcrypt hashes with === or strcmp().

Common Use Cases

User Password Storage

The primary use of bcrypt. Hash the password before inserting into the database — never store plaintext. On login, call password_verify($input, $storedHash). Even if the database is breached, the hashes resist cracking.

Migrating Weak Password Hashes

If your app uses MD5 or SHA-1 passwords, migrate to bcrypt on each successful login: verify the old hash, then immediately re-hash with bcrypt and store the new value. Use this tool to test the migration.

Cost Factor Tuning

Use this tool to benchmark different cost factors on your production hardware. Aim for 250ms–1s per hash. Move the cost slider and observe generation time to find the right balance between security and UX.

Verifying Stored Hashes

Use the Verify tab to confirm a password matches an existing bcrypt hash. Useful when debugging authentication issues or testing that a hash stored in the database was generated from the expected password.

API Key & Token Hashing

API keys can be stored as bcrypt hashes rather than plaintext. The user sees the key once at creation; the server stores only the hash and verifies on each request — minimizing exposure if the database is breached.

Security Auditing

Paste a hash from a database dump to verify its format ($2y$ vs older $2a$) and cost factor. A cost below 10 is considered underpowered by today's standards and should be re-hashed on next user login.

Related Developer Tools

Hash Generator
Random String Generator
Password Generator
JWT Decoder

Related Articles

View all articles
Bcrypt's 72-Byte Limit: Why Two Different Passwords Can Hash to the Same Value

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.

Jun 13, 2026
Credential Breaches and Stuffing Attacks: What Leaked Password Databases Reveal and How HIBP Works

Credential Breaches and Stuffing Attacks: What Leaked Password Databases Reveal and How HIBP Works

Have I Been Pwned has indexed 12+ billion breached accounts. Here's what a leaked credential database actually looks like, how attackers use credential stuffing at scale, the k-anonymity trick that lets HIBP check passwords without seeing them, and why bcrypt salting defeats rainbow tables.

Jun 12, 2026
Why bcrypt: The History of Password Hashing, Cost Factors, and When Argon2 Is Better

Why bcrypt: The History of Password Hashing, Cost Factors, and When Argon2 Is Better

SHA-1 and MD5 are fast by design — which is why GPUs crack them in hours after a breach. bcrypt's deliberate slowness and automatic salting are its defence. Here's how bcrypt works, the 72-byte limit, choosing a cost factor, and when Argon2 is the better choice.

Jun 9, 2026
Bcrypt Generator — Hash & Verify Passwords the Right Way

Bcrypt Generator — Hash & Verify Passwords the Right Way

Learn how bcrypt works, why slowness is the feature, what the cost factor means, how to use bcrypt for user authentication, and why MD5 and SHA-256 should never be used for passwords — with a free bcrypt generator.

Jun 7, 2026
Bcrypt Generator — How to Hash & Verify Passwords Correctly

Bcrypt Generator — How to Hash & Verify Passwords Correctly

Learn what bcrypt is, how the cost factor and salt work, how bcrypt hashes are structured, and how to use a free bcrypt generator to test and verify password hashes in your development workflow.

Jun 6, 2026