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

Bcrypt silently ignores everything past the first 72 bytes of a password — meaning "correcthorsebatterystaple-and-then-fifty-more-random-characters" and "correcthorsebatterystaple-and-then-fifty-DIFFERENT-random-characters" can hash to the exact same value, if the first 72 bytes match

Bcrypt has a maximum input length of 72 bytes — any characters beyond the 72nd byte are silently truncated before hashing. This is a long-standing, well-documented characteristic of the bcrypt algorithm — but it's also a frequently-overlooked detail that can produce surprising behavior with very long passwords, and has specific implications when combined with multi-byte (Unicode) characters.

Why 72 bytes specifically

Bcrypt's underlying algorithm (based on the Blowfish cipher) has a key-size limit of 448 bits = 56 bytes — but bcrypt's actual practical input limit is commonly cited as 72 bytes, due to implementation-specific details in how the password is used to initialize the cipher's internal state (involving some additional bytes beyond the raw 56-byte key limit, related to how the initialization process consumes input).

**The precise figure (72) and exactly why it's this number, rather than 56 or some other figure, involves implementation-specific details of how different bcrypt implementations handle the initialization — but the practical takeaway, across essentially all common bcrypt implementations, is: inputs longer than 72 bytes are truncated to 72 bytes before the hashing algorithm processes them — anything beyond byte 72 has no effect on the resulting hash.

The practical consequence: two "different" passwords, same hash

If a password is longer than 72 bytes, and two different passwords share the same first 72 bytes but differ only in characters beyond byte 72 — both passwords will produce the identical bcrypt hash, and both will be accepted as "correct" when verified against that hash.

Example (illustrative): if password = "a".repeat(72) + "XXXXXXXX" and password2 = "a".repeat(72) + "YYYYYYYY" — both have the same first 72 bytes (72 "a" characters) — bcrypt would hash both to the same result, and a user who set their password as password could successfully "log in" using password2 (or any other string sharing the same first 72 bytes), despite these being, character-for-character, different strings.

For most real-world passwords (which are, overwhelmingly, far shorter than 72 characters) — this never comes into play. It becomes relevant specifically for: (a) systems that allow (or encourage) very long passphrases (some "passphrase"-based approaches encourage long, multi-word phrases that could, in principle, exceed 72 characters), or (b) systems combining a user-provided password with additional data before hashing (e.g., concatenating a password with some other string server-side, before passing to bcrypt — if this concatenation produces inputs regularly exceeding 72 bytes, the truncation behavior becomes practically relevant).

Unicode characters: bytes, not characters

Bcrypt's 72-byte limit is measured in bytes, not characters — for multi-byte characters (most non-ASCII characters, in UTF-8 encoding, take 2-4 bytes each — covered in previous articles on Unicode/UTF-8) — a password containing many non-ASCII characters could reach the 72-byte limit with far fewer than 72 characters.

Example: a password consisting entirely of emoji (many of which are 4 bytes each in UTF-8) — just 18 such characters would already total 72 bytes (18 × 4 = 72) — any additional characters beyond this 18th emoji would be truncated, despite the password, in terms of "number of characters typed," being far shorter than what "72" might intuitively suggest to someone thinking in terms of "72 characters."

This creates a subtle, locale/input-method-dependent "effective maximum password length" — a password that's "X characters" long, if composed of ASCII characters (1 byte each), is well under the 72-byte limit — but the "same number of characters," if composed of multi-byte Unicode characters, could exceed the byte limit far sooner — the truncation point, in terms of "number of characters a user perceives themselves as having typed," varies depending on which characters are used.

Pre-hashing: a common mitigation

A common approach to avoid the 72-byte limitation entirely: hash the password with a fixed-output-length hash function (e.g., SHA-256, producing a fixed 32-byte output) before passing it to bcrypt — bcrypt(sha256(password)) rather than bcrypt(password) directly.

Why this helps: SHA-256's output is always 32 bytes, regardless of the input password's length — so the input to bcrypt (the SHA-256 hash, not the raw password) is always 32 bytes — well within bcrypt's 72-byte limit, regardless of how long the original password was (whether it's 8 characters or 800 characters, its SHA-256 hash is always 32 bytes).

Important caveat: this pre-hashing approach changes what bcrypt is actually hashing — bcrypt is now hashing "the SHA-256 hash of the password," not "the password itself." This is generally considered acceptable (SHA-256's output, for the purpose of being bcrypt's input, functions as a fixed-length representation of the password — bcrypt's own salting/cost-factor properties, covered in previous articles, still apply to this representation) — but it's a deliberate design choice, not something that happens automatically — if your bcrypt implementation/library doesn't document pre-hashing, it's likely not doing this, and the raw-password, 72-byte-truncation behavior applies directly.

Null bytes: a separate, historical issue in some implementations

A related, but distinct, historical issue: some older/specific bcrypt implementations have, at various points, had issues with null bytes (\0) within the input — truncating the input at the first null byte encountered, rather than processing the full input up to 72 bytes.

This is implementation-specific and less universally applicable than the 72-byte limit (which is a more fundamental, widely-shared characteristic of bcrypt itself) — but worth being aware of if working with older libraries, or if passwords might, for any reason, contain null bytes (which would be unusual for typical user-entered passwords, but could occur via certain input-handling bugs/encoding issues elsewhere in a system).

How to use the Bcrypt Generator on sadiqbd.com

1. For typical passwords (well under 72 bytes, which describes the vast majority of real-world passwords): the 72-byte limit is not practically relevant — bcrypt hashes the full password as expected
2. For very long passphrases, or passphrases with substantial non-ASCII content: be aware of the byte (not character) limit — if precision matters, checking the UTF-8 byte-length of a password (which this site's Character Frequency tool, or similar, could help estimate, given its Unicode-awareness discussed in previous articles) before assuming "it's under 72 characters, so it's fine"
3. If implementing pre-hashing (SHA-256-then-bcrypt) in your own systems: this is a deliberate, documented design choice you would make in your application code — this generator tool hashes whatever input you provide directly with bcrypt; if you want to test the "pre-hashed" approach, you'd need to compute the SHA-256 hash separately (e.g., via the Hash Generator tool on this site) and use that output as the input here

Frequently Asked Questions

Does the 72-byte limit make bcrypt "insecure" for long passwords? Not in any practical sense for typical use — the security of bcrypt comes from its cost factor (the computational expense of computing each hash, covered in previous articles) and its salting — neither of which is affected by the 72-byte limit. The limit means "passwords differing only beyond byte 72 are indistinguishable to bcrypt" — which, for the overwhelming majority of real-world passwords (far under 72 bytes), is simply not a relevant scenario — it's not that bcrypt "breaks" for long passwords; it's that very long passwords (beyond 72 bytes) don't get the "full" benefit of their additional length, which, given that bcrypt's cost-factor-based security doesn't fundamentally depend on password length beyond a reasonable threshold anyway (unlike, say, brute-force resistance for unsalted, fast hashes, where length matters enormously) — is generally not considered a significant practical security concern for typical usage.

Is the Bcrypt Generator free? Yes — completely free, no sign-up required.

Try the Bcrypt Generator free at sadiqbd.com — hash and verify passwords with bcrypt instantly.