If your Python app suddenly started throwing ValueError: password cannot be longer than 72 bytes, this is why. Originally published on BcryptGenerator.org.

Bcrypt's maximum password length is 72 bytes. Anything after the 72nd byte has no effect on the hash. That much has been true since 1999. What has changed is how libraries react to longer passwords: some still ignore the extra bytes silently, while newer ones refuse them with an error. That's why code that worked for years can suddenly throw ValueError: password cannot be longer than 72 bytes.

This guide explains where the limit comes from, why it's measured in bytes rather than characters, exactly what each popular library does (we tested them), and how to handle it safely.

Why 72 bytes?

Bcrypt is built on the Blowfish cipher, and it feeds the password into Blowfish's key setup. That key setup has room for 18 subkeys of 32 bits each: 576 bits, or 72 bytes. The original bcrypt paper by Provos and Mazières uses the password as that key, so the limit comes with the design.

It isn't a bug, and it doesn't make bcrypt insecure. A 72-byte password is extremely long. It becomes a problem when software assumes every byte of a long input counts, or when a library upgrade changes from silently ignoring extra bytes to rejecting them.

Bytes, not characters

The limit counts UTF-8 bytes. For plain English text, one character is one byte, but that isn't true for everything:

So a password manager phrase in Chinese, or a passphrase with a few emoji, can pass 72 bytes with far fewer than 72 characters. Measure bytes, not characters:

JavaScript has an extra trap: password.length counts UTF-16 code units, which are neither bytes nor characters. For 19 emoji it returns 38, while the real byte count is 76.

What each library does with longer passwords

We tested the libraries we could run. For the others, the table cites their official documentation.

Two patterns stand out. The libraries that ignore the extra bytes give no warning, so you only find out with a test. And the move toward rejecting long passwords is recent: Python's bcrypt 5.0.0 shipped in September 2025, and Spring changed after a 2025 security advisory.

"ValueError: password cannot be longer than 72 bytes" in Python and FastAPI

This is the full message from Python's bcrypt 5.0:

ValueError: password cannot be longer than 72 bytes, truncate manually if necessary (e.g. my_password[:72])

If you call bcrypt directly, it means the password really is over 72 bytes. The fixes are in the next section.

If you use passlib, which many FastAPI and Flask tutorials taught for years, the cause is different. Passlib fails on every password, even short ones. In our test, this tutorial-style code raised the error for the 28-character password correct horse battery staple:

from passlib.context import CryptContext

pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
pwd_context.hash("correct horse battery staple")  # ValueError with bcrypt 5.0

The reason is in passlib's own code. The first time it hashes anything, it runs a self-test that checks for an old bcrypt bug, using a 255-byte test password. bcrypt 5.0 rejects that test password, so passlib fails before your password is even looked at. You may also see (trapped) error reading bcrypt version with AttributeError: module 'bcrypt' has no attribute '__about__' in your logs. That's a separate, harmless compatibility warning. Passlib's last release, 1.7.4, came out in October 2020, before either change.

Your options:

1. Move off passlib (recommended). FastAPI's own security tutorial now uses pwdlib with Argon2id (pip install "pwdlib[argon2]"), which also has no 72-byte limit:

   from pwdlib import PasswordHash
   
   password_hash = PasswordHash.recommended()
   hashed = password_hash.hash(password)
   password_hash.verify(password, hashed)
   

   Existing bcrypt hashes still need a bcrypt verifier. FastAPI's tutorial suggests passlib for verifying old hashes while hashing new ones with Argon2, and the upgrade section below shows how to verify old bcrypt hashes with the bcrypt package.

2. Short-term: pin bcrypt==4.0.1. In our test, passlib worked again with it. This only buys time: it brings back silent truncation, and passlib itself is no longer maintained.

When ignoring bytes becomes a security bug

Silently ignoring bytes past 72 is harmless when the input is just a long password. It becomes dangerous when bcrypt is used to hash something longer and structured, where the important part might land after byte 72.

• Spring Security, CVE-2025-22228: BCryptPasswordEncoder.matches() returned true for passwords over 72 characters when only the first 72 matched. Patched versions now throw instead.
• Okta, 2024: Okta's advisory describes a cache key made by bcrypt-hashing user ID + username + password together. For usernames of 52 characters or more, a cached login could succeed without the correct password. The advisory doesn't spell out the mechanism, but the combination fits the limit: with a long enough user ID and username, the password starts past the bytes bcrypt reads. Okta switched to PBKDF2.

The lesson: only hash a user's password with bcrypt, never a concatenation that puts the password at the end.

How to handle the limit

Option 1: enforce a 72-byte maximum

This is the simplest fix and what OWASP's Password Storage Cheat Sheet recommends for bcrypt. Check the byte length at sign-up and password change, and show a clear message:

function assertBcryptLength(password) {
  if (Buffer.byteLength(password, 'utf8') > 72) {
    throw new Error('Password must be 72 bytes or fewer')
  }
}

def check_length(password: str) -> None:
    if len(password.encode("utf-8")) > 72:
        raise ValueError("Password must be 72 bytes or fewer")

The PHP version is in our PHP guide. Use a message users understand: "fewer than 72 characters, or fewer if you use emoji or non-Latin letters" is clearer than "bytes".

Option 2: pre-hash with a pepper

If you want to accept passphrases of any length, hash the password with a secret key first, and give bcrypt that fixed-length result. Do it carefully: OWASP warns that naive pre-hashing is dangerous because raw hash output can contain null bytes, which some implementations treat as the end of the password, and because of "password shucking" (attacking an unsalted pre-hash leaked elsewhere). Its recommended construction is bcrypt(base64(hmac-sha384(password, pepper))), with the pepper stored outside the database:

const crypto = require('crypto')
const bcrypt = require('bcrypt') // or 'bcryptjs'

// The pepper is a long random secret kept outside the database (env var or secrets manager)
function prepare(password) {
  return crypto.createHmac('sha384', process.env.PASSWORD_PEPPER).update(password, 'utf8').digest('base64')
}

const hash = await bcrypt.hash(prepare(password), 12)
const ok = await bcrypt.compare(prepare(password), hash)

import base64, hashlib, hmac, os
import bcrypt

PEPPER = os.environ["PASSWORD_PEPPER"].encode()

def prepare(password: str) -> bytes:
    digest = hmac.new(PEPPER, password.encode("utf-8"), hashlib.sha384).digest()
    return base64.b64encode(digest)  # 64 bytes, no null bytes

hashed = bcrypt.hashpw(prepare(password), bcrypt.gensalt())
bcrypt.checkpw(prepare(password), hashed)

The base64 result is always 64 bytes, under the limit, and contains no null bytes. In our tests, a 145-byte passphrase verified correctly, and the same passphrase with one character removed did not. Two caveats: the pepper becomes as important as the database (lose it and nobody can log in), and you must apply exactly the same prepare() at sign-up and login.

Option 3: use Argon2id for new systems

Argon2id has no 72-byte limit and is OWASP's first choice for new systems. In Python, pwdlib's PasswordHash.recommended() uses it. See bcrypt vs Argon2 for the trade-offs.

Upgrading without locking users out

Here's the trap when you move from a library that ignored extra bytes to one that rejects them. Users who chose long passwords years ago have hashes made from the first 72 bytes, and the new library now raises an error when they log in.

We reproduced this. A hash created by Python bcrypt 4.0.1 from an 87-byte password made bcrypt 5.0's checkpw() raise ValueError. The fix is to do exactly what the old library did, but only when verifying existing hashes:

def verify_legacy(password: str, stored: bytes) -> bool:
    # The old library ignored everything after byte 72, so do the same here
    return bcrypt.checkpw(password.encode("utf-8")[:72], stored)

That verified the user correctly and still rejected a wrong password. After a successful legacy login, re-hash the password with your new scheme (pre-hash or Argon2id) so the workaround is only ever needed once per user. If you also compare passwords in other places, check them for the same upgrade issue.

Checklist

• Your library's behaviour over 72 bytes is known (see the table), not assumed
• Sign-up and password change enforce 72 bytes, measured in bytes
• Or passwords are pre-hashed as bcrypt(base64(hmac-sha384(password, pepper)))
• bcrypt only ever hashes the password, never id + username + password
• Python apps on passlib have moved to pwdlib or bcrypt directly, or deliberately pinned bcrypt==4.0.1
• Hashes made by truncating libraries are verified with the first 72 bytes, then re-hashed
• New systems consider Argon2id

Want to see the limit in action? The bcrypt generator warns you as soon as a password passes 72 bytes, and the bcrypt checker shows the cost and version of any hash.

Drafted with AI assistance; reviewed and tested by Shahzeb Zafar.

This article first appeared on BcryptGenerator.org, where you can also generate and check bcrypt hashes in your browser.

Every week someone asks how to "decrypt" a bcrypt hash. Here is the short answer, and what to do instead. Originally published on BcryptGenerator.org.

No, a bcrypt hash can't be decrypted. Not online, not with the salt, and not with a key, because there is no key. Bcrypt is a one-way hash: it turns a password into a fixed string, and there's no operation that turns that string back. The only way to learn the password behind a bcrypt hash is to guess passwords and check each guess, and bcrypt is deliberately designed to make that slow.

That's usually not what you actually need, though. Below are the things people searching "bcrypt decrypt" are usually trying to do, and how to do each one.

Is bcrypt encryption or hashing?

Hashing. The difference matters:

Encryption is for things your program must read back later, like a stored API token. Passwords should never be stored that way; OWASP's Password Storage Cheat Sheet recommends hashing them with a slow algorithm such as Argon2id or bcrypt. If the server can decrypt them, so can anyone who steals the server's key. With a hash, a stolen database contains nothing to decrypt. See what bcrypt is and how it works for the full picture.

What you can read from a bcrypt hash

A bcrypt hash isn't completely opaque. Its first parts are stored in plain view, which is what "bcrypt decoder" tools show you:

const hash = '$2b$12$RB2qR6GI4quP.PUs6xR5He37dCyunLcYFzlvUfwSX41XkRXgOQ3OS'
const [, version, cost, rest] = hash.split('$')
console.log({ version, cost: Number(cost), salt: rest.slice(0, 22), checksum: rest.slice(22) })
// { version: '2b', cost: 12, salt: 'RB2qR6GI4quP.PUs6xR5He', checksum: '37dCyunLcYFzlvUfwSX41XkRXgOQ3OS' }

That tells you the bcrypt version, the cost (how slow each check is), and the random salt. It does not reveal anything about the password. The last 31 characters are the actual hash output. The bcrypt checker shows the same breakdown for any hash you paste.

"Can I decrypt it with the salt?"

No. The salt isn't a secret or a key; it's stored right inside the hash, as shown above. Its job is to make every hash unique, so that two users with the same password get different hashes and attackers can't use precomputed tables. Having the salt is normal: every attacker who steals a bcrypt database has every salt, and it still doesn't let them reverse anything.

What "bcrypt decrypt online" sites actually do

Sites offering to "decrypt" bcrypt can only do one thing: guess. They take a list of common passwords, hash each one with the salt and cost from your hash, and see whether any result matches. It works only if the password was weak or common, like password123 or qwerty.

Bcrypt makes even that slow on purpose. In the PHP project's measurements for its 2023 RFC, a single cost-12 bcrypt hash took about 160–330 milliseconds on ordinary CPUs. Every guess costs that much again, so trying even a modest list of common passwords takes real time, and a long, random password is out of reach. That's the whole point of bcrypt.

Two warnings:

• Don't paste real users' hashes into third-party sites. You're handing someone else material they can try to crack, and possibly the user's email next to it.
• "Decrypted" results only mean the password was guessable. If a site "decrypts" your hash, treat that password as compromised.

What you probably need instead

Check whether a password matches a hash

You don't need to decrypt anything. Hash the candidate password with the same salt and compare, which is exactly what every bcrypt library's compare function does:

const bcrypt = require('bcryptjs')
console.log(await bcrypt.compare('correct horse battery staple', hash)) // true
console.log(await bcrypt.compare('password123', hash))                  // false

Or paste the hash and password into the bcrypt checker, which does this in your browser. In PHP use password_verify(), and in Python bcrypt.checkpw(). If a check fails for a password you're sure is right, see why bcrypt.compare() returns false.

Reset a forgotten password (including your own admin account)

If you've lost the password to an account you control, you can't recover it, and you don't need to. Set a new one: generate a fresh hash and write it over the old one. Generate the hash with any of these one-liners (each produced a working cost-12 hash in our tests):

node -e "require('bcryptjs').hash('NewPassword!2026', 12).then(console.log)"

php -r "echo password_hash('NewPassword!2026', PASSWORD_BCRYPT, ['cost' => 12]), PHP_EOL;"

python -c "import bcrypt; print(bcrypt.hashpw(b'NewPassword!2026', bcrypt.gensalt(12)).decode())"

Or use the bcrypt generator in your browser. Then save it to the user's row:

UPDATE users SET password_hash = '$2b$12$...your new hash...' WHERE email = 'admin@example.com';

Use a real new password rather than the example, and clear it from your shell history afterwards. For other people's accounts, use your app's normal password-reset email flow instead of editing the database.

Laravel: Laravel rejects hashes that start with $2b$ (the Node and Python output) unless you change the first four characters to $2y$. The PHP one-liner already produces $2y$. Our PHP and Laravel guide explains why.

Move users to a new system

Migrating to a new app or framework doesn't require decrypting passwords either. Bcrypt hashes are portable. In our tests, hashes created by PHP, Node.js and Python verified in each other's libraries, so you copy the hashes as they are, and users keep their passwords. The one exception was Node's native bcrypt package, which rejected PHP's $2y$ hashes until the prefix was changed to $2b$ (details). Just make sure the new database column is long enough: a bcrypt hash is 60 characters, and too-short columns break logins.

Quick answers

Is bcrypt reversible? No. There's no reverse function; you can only check guesses.

Can bcrypt be decrypted with a key? No. Bcrypt doesn't use a key. If someone gives you a "key" to decrypt bcrypt, they're mistaken or scamming you.

Can a bcrypt hash be decoded? Partly. The version, cost and salt are readable (see above), but the password isn't.

Is bcrypt still secure if attackers get the database? It holds up well for strong passwords, which is why it's used. Weak passwords can still be guessed, just slowly. See how many bcrypt rounds to use for choosing a cost that keeps guessing expensive.

What about files ending in .bfe? That's a different, older tool that's also called bcrypt: a command-line file encrypter built on Blowfish. Those files can be decrypted, with the passphrase used to create them. It has nothing to do with password hashes.

Drafted with AI assistance; reviewed and tested by Shahzeb Zafar.

This article first appeared on BcryptGenerator.org, where you can also generate and check bcrypt hashes in your browser.