Bcrypt Hash Checker
Generate bcrypt hashes and verify plaintext against existing hashes.
Reviewed by the ToolNestr Editorial Team — July 2026
How bcrypt hashing works
Bcrypt is an adaptive cryptographic hash function designed for password hashing by Niels Provos and David Mazières in 1999. It is based on the Blowfish cipher and incorporates a salt to protect against rainbow table attacks. The "adaptive" nature means the cost factor (salt rounds) can be increased over time to counter faster hardware, making bcrypt future-proof for password storage.
When you hash a password with bcrypt, the function generates a random 16-byte salt (encoded as 22 base64 characters), then performs 2rounds iterations of the key derivation process using the Blowfish cipher. The output is a 60-character string in the format: $2b$10$salt22charshashed31chars. The $2b$ prefix identifies the algorithm version, 10 is the cost factor (210 = 1,024 iterations), followed by the salt and the 184-bit hash output.
Because the salt is randomly generated each time, the same password produces a different hash on every invocation. This prevents attackers from using precomputed lookup tables and ensures that users sharing the same password still get distinct stored hashes.
Worked example
The bcrypt hash format
Every bcrypt hash follows a strict format: $2b$10$abc123...xyz. The $2b$ prefix indicates the algorithm version. Earlier versions used $2a$ (original) and $2x$/$2y$ (bug-fix variants). Modern implementations use $2b$ exclusively because it correctly handles the 8-bit character encoding issue that affected $2a$.
The second field (two digits) is the cost factor — the exponent used for the number of iterations (2cost). A cost of 10 means 1,024 iterations; cost 12 means 4,096 iterations; cost 14 means 16,384 iterations. The cost is stored as a zero-padded two-digit number from 04 to 31.
The remaining 53 characters contain the 22-character base64-encoded salt and the 31-character base64-encoded hash output (184 bits). The base64 variant used by bcrypt differs from standard base64 — it uses a custom alphabet (. through / following A-Za-z0-9 ordering) that is incompatible with standard base64 encoding.
Application Developer
Implements bcrypt for user registration and login systems. Hashes passwords on signup and verifies them on login, ensuring plaintext passwords are never stored in the database.
Security Engineer
Audits password storage practices and recommends bcrypt with appropriate cost factors. Ensures compliance with OWASP guidelines for credential storage.
API Backend Developer
Uses bcrypt to hash API tokens and client secrets before storing them. Verifies tokens on each authenticated request without exposing the original secret.
DevOps / Sysadmin
Configures authentication systems that rely on bcrypt for shadow password files, VPN credentials, and internal tool authentication.
Choosing the right salt rounds
The cost factor (salt rounds) determines how computationally expensive each hash operation is. A higher cost provides stronger protection but increases the time required to hash and verify. The table below shows approximate hashing times on modern hardware (2025 baseline: single core):
| Rounds | Iterations | Approx. Time | Recommendation |
|---|---|---|---|
| 4 | 16 | < 1 ms | Testing only — no security |
| 8 | 256 | ~5 ms | Low-security internal tools |
| 10 | 1,024 | ~50 ms | Standard for most applications |
| 12 | 4,096 | ~200 ms | Recommended for sensitive data |
| 14 | 16,384 | ~800 ms | High-security / admin accounts |
| 16 | 65,536 | ~3.2 s | Maximum — may affect UX |
For most production web applications, 10–12 salt rounds strike the right balance between security and user experience. High-security environments (financial services, healthcare) should use 12–14 rounds. Always benchmark on your production hardware before choosing a cost factor, and plan to increase it as hardware improves over time.
Bcrypt use cases
Storing user passwords
The most common use case for bcrypt is password storage. When a user creates an account, the application hashes their password with bcrypt before storing it in the database. The original password is never stored. When the user logs in, the application hashes the provided password with the same salt extracted from the stored hash and compares the results. This means even if the database is compromised, the attacker only gains access to the bcrypt hashes — cracking them requires significant computational resources for each password.
Verifying login credentials
During login, bcrypt's verification function extracts the salt and cost factor from the stored hash, re-hashes the provided password with those parameters, and compares the results. This process is intentionally slow (configurable via the cost factor) to frustrate brute-force attacks while remaining transparent to legitimate users who only authenticate once per session.
Securing API tokens and secrets
Applications often generate API keys or bearer tokens that act as long-lived credentials. Instead of storing these tokens in plaintext, services hash them with bcrypt at issuance time. On each API request, the provided token is verified against the stored hash. If the token database is breached, the attacker cannot use the hashes to authenticate — they would need to crack each bcrypt hash individually.
Bcrypt vs other password hashing algorithms
| Algorithm | Salt | Adaptive | Memory Hard | Best For |
|---|---|---|---|---|
| Bcrypt | Yes (16 bytes) | Yes (rounds) | No | General password storage |
| Argon2id | Yes (16+ bytes) | Yes (iterations, memory, threads) | Yes | New applications (gold standard) |
| PBKDF2 | Yes | Yes (iterations) | No | Legacy systems, FIPS compliance |
| scrypt | Yes | Yes (CPU + memory) | Yes | Memory-hard alternative to bcrypt |
| SHA-256 (raw) | No | No | No | Not suitable for passwords (too fast) |
How to use Bcrypt Hash Checker
Switch to Hash mode
Select the "Hash" tab. Enter any plaintext and choose the number of salt rounds (4–16, default 10).
Generate the hash
Click "Generate Hash" to compute the bcrypt hash. The result is a 60-character string starting with $2b$.
Verify an existing hash
Switch to "Verify" mode, enter a plaintext and a bcrypt hash, then click "Verify" to check if they match.
Tips for using bcrypt
Use 10–12 salt rounds for production
A cost factor of 10 provides adequate security for most web applications and completes in ~50 ms on modern hardware. For sensitive data like financial or healthcare information, use 12–14 rounds. Always benchmark on your production infrastructure before choosing a cost factor. Remember that Moore's law means you should plan to increase the cost over time — bcrypt's adaptive design makes this straightforward.
Never truncate user passwords
Bcrypt has a maximum input length of 72 bytes. Passwords longer than 72 characters are silently truncated to 72 bytes by some implementations. If your application accepts long passwords, either warn users about the 72-byte limit or pre-hash the password (e.g. with SHA-256) before passing it to bcrypt. Most libraries now handle this correctly, but it is worth verifying.
Use constant-time comparison
Bcrypt's verify function performs a constant-time comparison by default, meaning it takes the same amount of time regardless of how many characters match. This prevents timing attacks where an attacker could determine how close a guessed password is to the correct one by measuring response times. Never implement your own comparison — always use the library's built-in verify function.
Consider Argon2id for new projects
While bcrypt remains an excellent choice and is battle-tested, the OWASP recommended algorithm for password hashing is Argon2id. Argon2id is memory-hard, meaning it resists GPU- and ASIC-based attacks more effectively than bcrypt. If you are starting a new project and your platform supports Argon2id, it is worth considering. However, bcrypt is still vastly superior to raw SHA-256 or unsalted MD5 for password storage.
What is bcrypt?
Bcrypt is a password-hashing function designed by Niels Provos and David Mazières, based on the Blowfish cipher. It was presented at USENIX in 1999 and has since become one of the most widely used password hashing algorithms in the world. Bcrypt's key innovation is its adaptive cost factor: the "salt rounds" parameter determines how many iterations of the Blowfish key schedule are performed, making the hash deliberately slow to compute.
Each bcrypt hash incorporates a 128-bit (16-byte) salt generated by a cryptographically secure random number generator. The salt is stored as part of the hash output, which means every call to the hash function with the same password produces a completely different result. This defeats rainbow tables and ensures that users with identical passwords still get unique stored hashes.
Bcrypt is classified as a "password hashing function" (PHF) rather than a general-purpose hash. Unlike SHA-256 or MD5, which are designed to be fast, bcrypt is intentionally slow to make brute-force attacks economically infeasible. As computing power increases, the cost factor can be raised to maintain security — this adaptability is what makes bcrypt future-proof.
How bcrypt generates hashes
Bcrypt works by first initializing the Blowfish cipher with a key schedule derived from the password and salt. The key schedule (EksBlowfishSetup) performs 2cost iterations of the Blowfish key expansion, where each iteration mixes the password and salt into the cipher's internal state (4,608 bytes of S-boxes and P-array). This heavy memory usage makes bcrypt resistant to GPU-based parallel attacks.
After key setup, bcrypt encrypts the string "OrpheanBeholderScryDoubt" (192 bits / 24 bytes) using the initialized Blowfish cipher 64 times. The result of this encryption is the 184-bit hash output, which is then encoded along with the salt and cost factor into the standard $2b$10$... format. The entire process is deterministic given the same password, salt, and cost — making verification possible by repeating the same computation.
Bcrypt and security compliance
Bcrypt meets the password storage requirements for most regulatory frameworks including GDPR, HIPAA, PCI-DSS, and SOC 2. PCI-DSS requirement 3.5 specifically mandates that stored passwords must be one-way hashed using strong cryptography — bcrypt qualifies with appropriate cost factors. Many compliance auditors explicitly look for salted, adaptive hashing when reviewing password storage implementations.
When using bcrypt for compliance, document your chosen cost factor and the rationale behind it. Set up a migration strategy to increase the cost factor over time (for example, re-hash passwords on user login with an updated cost). Maintain audit logs showing that plaintext passwords are never stored or logged at any point in the authentication flow.
Related tools
Frequently asked questions
What is bcrypt?
An adaptive password-hashing function that includes a salt to protect against rainbow table attacks.
What are salt rounds?
The work factor: more rounds (e.g. 12) means slower hashing and stronger protection against brute-force.
Is this the same as encryption?
No — hashing is one-way. You cannot recover the original text from a bcrypt hash.
Can I verify a password against a hash?
Yes — enter a password and an existing hash to check if they match.