Bcrypt has a quirk that surprises a lot of developers: it only processes the first 72 bytes of a password. Everything after that is silently ignored. If a user picks a 200-character passphrase thinking they are being extra secure, bcrypt is only protecting the first 72 bytes of it. The rest might as well not exist.
For most applications, this is a non-issue. The vast majority of passwords are well under 72 bytes. But if you are building a system that encourages long passphrases, or if you just want to understand exactly what your password hashing is doing, you need to know about this limit and how to handle it.
Why the 72-Byte Limit Exists
The limit comes from bcrypt's underlying algorithm. Bcrypt is based on the Blowfish cipher's key scheduling function, and Blowfish uses a 72-byte key. When bcrypt processes a password, it treats the password as the key for the Blowfish key schedule. Since Blowfish only reads 72 bytes of key material, bcrypt only reads 72 bytes of password.
This was not a design flaw when bcrypt was created in 1999. At the time, 72 bytes seemed like more than enough for any password. A 72-byte password is 72 ASCII characters, which is far longer than anyone was using in 1999. Even today, 72 characters is longer than the vast majority of passwords.
The limit becomes relevant when you consider passphrases. Security experts increasingly recommend passphrases like "correct horse battery staple" or even longer ones like "I always drink coffee at 7am before checking my email." These are great for memorability and entropy, but if they exceed 72 bytes, the extra characters are wasted.
It is also relevant for multibyte encodings. In UTF-8, a single Chinese, Japanese, or Korean character typically takes 3 bytes. That means the 72-byte limit is effectively 24 characters for CJK text. A Japanese user with a 30-character password would have the last 6 characters ignored.
What Happens with Longer Passwords
Here is the important part: bcrypt does not error or warn when a password exceeds 72 bytes. It silently truncates. The password "A" (1 byte) and "A" followed by 100 random characters (101 bytes) would produce the exact same bcrypt hash.
This means two things in practice:
**No additional security from extra length.** If a user picks a 150-character passphrase, only the first 72 bytes are contributing to security. The user might think they have an extremely strong password, but bcrypt is only protecting a 72-byte prefix of it.
**Potential false matches.** Two passwords that share the same first 72 bytes will verify against the same bcrypt hash. This is extremely unlikely with random passwords, but it is a theoretical concern.
In most real-world scenarios, this is not a problem. A 72-byte password (even with only ASCII characters) has more entropy than any human could memorize. The issue is more about honesty: if your UI tells users "longer passwords are more secure" and then bcrypt silently truncates them, that is misleading.
How to Check If the Limit Affects Your Users
The simplest approach is to check how many of your users actually have passwords longer than 72 bytes. You cannot directly measure password lengths (you should not have access to plaintext passwords), but you can log the length of submitted passwords during login (without storing the passwords themselves).
If fewer than 0.1% of your users exceed 72 bytes, the limit is academic. You can document it and move on. If a significant number of users use long passphrases, you should consider a workaround.
Pre-Hashing: The Common Workaround
The most widely used workaround is pre-hashing: hash the password with SHA-256 first, then pass the resulting hash to bcrypt.
pre_hash = SHA256(password) // always 32 bytes, regardless of password length bcrypt_hash = bcrypt(pre_hash, cost=12)
Since SHA-256 always produces a 32-byte output, the bcrypt input is always well under the 72-byte limit, no matter how long the original password is. This effectively removes the length limit.
However, pre-hashing introduces a subtle issue that you should understand. When you pre-hash, you are creating a fixed mapping from plaintext passwords to SHA-256 hashes. If two different applications both use SHA-256 + bcrypt, and a user reuses the same password in both, the bcrypt hashes will be identical (assuming the same salt, which is unlikely but possible). This is not a practical concern with bcrypt's random salts, but it is worth knowing.
A more robust variant is to include a domain separator in the pre-hash to make it application-specific:
pre_hash = SHA256("myapp:" + password) bcrypt_hash = bcrypt(pre_hash, cost=12)
This ensures that even if the same password is used in another application with the same pre-hashing scheme, the pre-hashes will differ.
The Security Implications of Pre-Hashing
Pre-hashing with SHA-256 does not weaken bcrypt's security in any meaningful way. The SHA-256 step is fast, but it does not make the overall hash faster to compute because the bcrypt step (which is slow) still dominates. An attacker still needs to crack the bcrypt layer, which is the expensive part.
There is one theoretical concern: if an attacker can find a collision in SHA-256 (two different passwords that produce the same SHA-256 hash), they would also produce the same bcrypt hash. However, SHA-256 collisions have never been found and are considered computationally infeasible. This is not a practical concern.
The real tradeoff with pre-hashing is complexity. You are adding a step to your hashing pipeline, which means more code, more potential for bugs, and more to explain to future developers. If you do not need to support passwords longer than 72 bytes, it is simpler to just accept the limit.
Should You Worry About This?
For most applications, the answer is no. Here is a simple decision framework:
**If your users typically use short passwords (under 72 bytes):** Do nothing. The limit does not affect you. Document it if you want to be thorough, but do not add complexity for a problem you do not have.
**If you encourage long passphrases:** Either pre-hash with SHA-256 (and include a domain separator) or consider switching to Argon2id, which does not have a length limit. You can read more about Argon2id in our bcrypt vs Argon2 vs scrypt comparison.
**If you have many users with multibyte passwords (CJK languages):** The 72-byte limit is effectively 24 characters, which is more likely to be exceeded. Consider pre-hashing or at minimum make sure your password validation accepts the full password even if bcrypt truncates it, so users are not confused by a password that works on some systems but not others.
**If you are migrating from another algorithm:** Be careful. If you are using the dual-hash migration strategy described in our migration guide, make sure the old hash (which might be longer than 72 bytes for SHA-256 hex strings) is handled correctly. A SHA-256 hex string is 64 bytes, which is under the limit, but if you are using base64 encoding it could exceed 72 bytes.
The Bottom Line
The 72-byte limit is a real limitation of bcrypt, but it is not a vulnerability. It is a design decision from 1999 that has not been a practical problem for the vast majority of applications. If you are aware of it and handle it appropriately (either by accepting it or by pre-hashing), it does not reduce your security.
The most important thing is to not mislead your users. If your UI says "longer passwords are more secure" but bcrypt truncates at 72 bytes, either fix the hashing or fix the messaging. Honesty about what your system actually protects is always better than a false sense of security.
For a complete overview of how bcrypt works, including the hash format and cost factor, read our bcrypt explained post. And to experiment with bcrypt hashing yourself, try our bcrypt generator.
