bcrypt Hash Generator

Free online bcrypt Hash Generator tool. 100% local processing — your data never leaves your device.

General
Password Hashing / KDF
Specialized
Deprecated
Output

Result will be displayed here...

Input → Calculate Hash

Usage Guide

About bcrypt

bcrypt is a password hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. It was specifically built to be slow and computationally expensive, making brute-force attacks impractical. bcrypt is one of the most widely deployed password hashing algorithms in the world, supported natively by frameworks like Rails, Django, Laravel, and Node.js (bcryptjs). Each bcrypt hash embeds a random salt and the cost factor, so the hash is fully self-contained for verification.

Battle-Tested Standard: bcrypt has been in production use for over 25 years and remains a reliable choice for password storage. OWASP recommends a minimum cost factor of 10, with cost=12 as the 2023 baseline. For new projects, Argon2id is preferred; bcrypt remains fully reliable for existing systems.

Usage Steps

This tool supports two operations: hashing a password (Encrypt) and verifying a password against a hash (Decrypt):

•
1. Hash Mode (Encrypt)Select 'Encrypt' mode, enter the password in the input box, then click 'Calculate Hash'
•
2. Get the HashThe output is a 60-character bcrypt string like $2b$12$... — copy and store it in your database
•
3. Verify Mode (Decrypt)Select 'Decrypt' mode, enter password|$2b$12$... (pipe-separated) in the input box, then click 'Decrypt'
•
4. Check ResultThe tool returns '✓ Password matches' if the password is correct, or an error message if it does not match
Privacy Protection: All bcrypt computations run entirely in your browser using WebAssembly. No data is ever sent to a server — completely offline processing.

Algorithm Features

bcrypt has several properties that make it well-suited for password storage:

•
Intentionally SlowThe Blowfish key schedule is expensive to compute, making each hash attempt slow and brute-force attacks costly
•
Built-in SaltEvery hash includes a unique 128-bit random salt, preventing rainbow table and identical-password attacks
•
Adjustable Cost FactorThe cost factor (4–31) controls work: each increment doubles computation time, letting you keep pace with hardware improvements
•
GPU ResistanceThe Blowfish key schedule's memory access patterns limit GPU parallelism compared to simpler hash functions like MD5 or SHA-256
•
Self-Contained HashThe 60-char output ($2b$12$[22-char salt][31-char hash]) includes all parameters needed for verification — no extra metadata required
Limitation vs Argon2: bcrypt uses only ~4 KB of memory during computation, making it significantly less resistant to ASIC and custom-hardware attacks than Argon2, which requires megabytes of memory. For new projects, prefer Argon2id. bcrypt is still appropriate for maintaining existing systems.

Cost Factor Guide

Choosing the right cost factor balances security against server performance:

•
Cost 10OWASP minimum (2023). ~100 ms on a modern server. Acceptable for low-traffic sites or resource-constrained environments
•
Cost 12OWASP 2023 baseline recommendation. ~400 ms. Good balance of security and performance for most web applications
•
Cost 14~1.5 s. High security for sensitive applications (finance, healthcare). May require async handling to avoid UI blocking
•
Cost 31 (max)Theoretical maximum — computation takes hours. Never use in production; only for offline archival or demonstration purposes
Tuning Tip: Benchmark on your production hardware and target 200–500 ms per hash. As CPUs improve over the years, increment the cost factor to maintain the same wall-clock time. New hashes can use the updated cost; existing hashes remain verifiable because the cost is stored in the hash string itself.

FAQ

Q: What is the bcrypt output format?

A: A bcrypt hash is always exactly 60 characters long and looks like: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Breaking it down:
$2b$: bcrypt version identifier (2b is the current standard; older hashes may show 2a or 2y).
12$: The cost factor (work factor), here 12.
Next 22 characters: Base64-encoded 128-bit random salt.
Final 31 characters: Base64-encoded 184-bit derived hash.
Key property: All parameters are embedded in the string — no additional storage is needed to verify a password later.

Q: How does bcrypt compare to Argon2?

A: bcrypt (1999): computation-hard, ~4 KB memory, moderate GPU resistance, universally supported across languages and frameworks. Argon2 (2015): memory-hard (configurable, default 64 MB), much stronger ASIC/GPU resistance, OWASP and NIST preferred algorithm. When to use bcrypt: Maintaining an existing system that already uses bcrypt, or working in an environment where Argon2 is not yet available. When to use Argon2: All new projects — it provides superior security at comparable or better performance. Migration: bcrypt and Argon2 hashes can be identified by their prefix ($2b$ vs $argon2id$), enabling gradual side-by-side migration.

Q: Why can't bcrypt be used to hash files or large data?

A: bcrypt has a 72-byte input limit. Any characters beyond the 72nd byte are silently ignored — two passwords that share the same first 72 bytes will produce the same hash, which is a security vulnerability. For file integrity or general data hashing, use SHA-256 or SHA-512. bcrypt is purpose-built for short, human-entered passwords only. If you need to hash long secrets (e.g., OAuth tokens), pre-hash the secret with SHA-256 first, then pass the hex digest to bcrypt — but for such use cases, consider Argon2 instead.

Q: Is bcrypt safe if my database is compromised?

A: Yes — a bcrypt hash is one-way: there is no algorithm to reverse it back to the original password. An attacker who steals your database must crack each hash individually by guessing passwords and running bcrypt (a slow operation). With cost=12, a single CPU core can attempt roughly 2–5 hashes per second, making exhaustive attacks against strong passwords effectively infeasible. However, bcrypt does not protect weak or common passwords (e.g., “password123”) — always enforce a minimum password strength policy and consider breached-password screening (e.g., Have I Been Pwned API) at registration.

Q: What cost factor should I use in production?

A: OWASP 2023 recommendation: cost=12 as the baseline. The right value depends on your server hardware: Benchmark approach: Run bcrypt on your production server and choose the highest cost factor that keeps hashing under 500 ms. This gives attackers the worst possible time-per-guess ratio without degrading user experience. Minimum floor: Never go below cost=10 for production user passwords. Over time: Revisit every 2–3 years as hardware improves — increment the cost factor and rehash passwords on next login. Note: The cost factor is stored in the hash, so old and new hashes with different costs can coexist and both verify correctly.

Q: Can bcrypt be used for API key or token storage?

A: Yes, with caveats. bcrypt is suitable for hashing API keys and tokens that are shorter than 72 bytes and infrequently verified. Since API keys are typically high-entropy random strings, the main risk from a leaked database is lower than for user passwords — a SHA-256 + salt approach may be sufficient and much faster for this use case. Avoid bcrypt for high-frequency verification (e.g., every API request) — instead, hash the token once at issuance, store the hash, and use a fast constant-time comparison. For session tokens and JWTs, use HMAC-SHA256 signing rather than bcrypt hashing.

Use Cases

Recommended: User Password Storage

This is bcrypt's primary use case and where it excels. When a user registers or changes their password, hash it with bcrypt (cost ≥ 12) and store the 60-character string in the database. During login, extract the stored hash, run bcrypt verification with the user-entered password, and compare. Because the salt and cost are embedded in the hash string, no extra columns are needed. bcrypt is supported out-of-the-box in Rails (has_secure_password), Django (default hasher), Laravel (Hash facade), and Node.js (bcryptjs / bcrypt packages).

Recommended Configuration:
  • ✅ bcrypt (cost ≥ 12, widely supported — recommended for existing systems)
  • ✅ Argon2id (preferred for new projects — stronger ASIC resistance)
  • PBKDF2-SHA256 (≥ 600k iterations, FIPS-compliant environments)
  • ❌ Don't use SHA-256, MD5, or other general-purpose hashes for passwords
Recommended: Legacy System Compatibility

Many production systems store millions of bcrypt hashes accumulated over years. Switching algorithms wholesale would invalidate every existing hash and force all users to reset passwords — a disruptive and risky operation. For these systems, continue using bcrypt and raise the cost factor as hardware improves. When new users register or existing users change passwords, you can transparently upgrade to Argon2id while bcrypt hashes (identified by $2b$ prefix) continue to verify correctly alongside the new ones.

Recommended Configuration:
  • ✅ Keep bcrypt for existing hashes — no forced migration needed
  • ✅ Gradually introduce Argon2id for new and updated passwords
  • ✅ Use hash-prefix detection ($2b$ vs $argon2id$) to route verification
  • 💡 Log the algorithm used per user to track migration progress
Acceptable: API Key Hashing

bcrypt can hash API keys before database storage, so a leaked database doesn't expose usable credentials. Since API keys are random high-entropy strings, brute-forcing bcrypt hashes is impractical even at lower cost factors (cost=10). However, bcrypt should only be used here if API key verification is infrequent (e.g., once per session). For per-request verification at scale, prefer a fast HMAC-SHA256 scheme or store a SHA-256 hash of the key (high-entropy keys make rainbow tables useless). Never store API keys in plaintext.

Recommended Configuration:
  • ✅ bcrypt (cost=10–12, good for low-frequency verification)
  • ✅ SHA-256 + salt (faster, suitable for high-entropy keys)
  • ✅ HMAC-SHA256 (for per-request token signing)
  • 💡 Use a hash prefix (first 8 chars) as a database index for fast lookup
Not Recommended: File or Data Encryption

bcrypt is a one-way hash function, not an encryption algorithm — there is no decryption step. It cannot encrypt files or arbitrary data. Additionally, bcrypt's 72-byte input limit makes it unsuitable for hashing file contents or large strings. For file encryption, use a symmetric cipher (e.g., AES-256-GCM). If you need to derive an encryption key from a password, use a key derivation function: Argon2id or scrypt are better suited for this purpose than bcrypt.

Recommended Configuration:
  • ❌ Don't use bcrypt for file encryption (it's not reversible)
  • ❌ Don't hash data longer than 72 bytes with bcrypt
  • ✅ Use AES-256-GCM for symmetric file encryption
  • ✅ Use Argon2id or scrypt for password-based key derivation
Not Recommended: General Data Hashing

bcrypt is too slow for general-purpose data integrity checks, content fingerprinting, deduplication, or any scenario where you need to hash large volumes of data quickly. For these needs, use a fast cryptographic hash: SHA-256 or SHA-512 for integrity verification, or BLAKE2/SHA-3 for high-performance scenarios. The deliberate slowness of bcrypt is an asset for password storage but a liability everywhere else.

Recommended Configuration:
  • ❌ Don't use bcrypt for data integrity checks or content hashing
  • ✅ SHA-256 (general-purpose integrity hashing)
  • ✅ BLAKE2b (high-speed cryptographic hashing)
  • ✅ SHA-3 / SHA-512 (higher security margin)
Not Recommended: High-Frequency Authentication

bcrypt is designed to be slow (~200–500 ms at cost=12). Running it on every API request or WebSocket message would bring your server to its knees. High-frequency authentication should rely on stateless tokens (JWT signed with HMAC-SHA256 or EdDSA) or server-side sessions with fast token lookups. bcrypt is only invoked once at login — after a successful password verification, issue a short-lived signed token that subsequent requests present for fast, bcrypt-free authentication.

Recommended Configuration:
  • ❌ Don't run bcrypt on every API request
  • ✅ JWT + HMAC-SHA256 (stateless, fast per-request auth)
  • ✅ Session + Cookie (traditional server-side session management)
  • ✅ OAuth 2.0 / OpenID Connect (federated identity, token-based)

Best Practice Summary

  • Use bcrypt (cost ≥ 12) for user password storage in existing systems. For new projects, prefer Argon2id — it offers stronger ASIC resistance with comparable performance.
  • Never use bcrypt for general data hashing, file encryption, or data larger than 72 bytes. It is purpose-built for short human-entered passwords.
  • Benchmark on your production hardware and target 200–500 ms per hash. Increment the cost factor every 2–3 years as hardware improves.
  • For high-frequency auth scenarios, use bcrypt only at login, then issue JWT or session tokens for subsequent requests.
  • Gradual migration from bcrypt to Argon2id: keep bcrypt for existing hashes, use Argon2id for new and updated passwords, identify algorithm by hash prefix.

Discussion & Feedback

0 comments
Me