How Bcrypt works
Bcrypt is a password hashing function designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. It is explicitly designed to be slow and resource-intensive, protecting passwords against brute-force and hardware-accelerated dictionary attacks.
Three key properties define bcrypt. First, it is adaptive: you can increase the work factor (rounds) to make it slower, keeping pace with faster hardware. Second, it includes a built-in 128-bit salt: a random value appended to the hash to prevent rainbow table attacks. Third, it is one-way: it cannot be decrypted to reveal the original password.
In the browser, bcrypt's computational cost means high rounds can block the main thread. To avoid freezing the user interface, Syntaxly executes all hashing and verification inside a background Web Worker using the client-side bcryptjs library. No data is ever sent to a server.
Properties & common uses
What the algorithm guarantees about every digest it produces.
Where a slow, adaptive hashing is required to secure user secrets.
Bcrypt vs MD5 vs SHA-256
| Algorithm | Type | Speed | Best for Passwords |
|---|---|---|---|
| MD5 | General Hash | Extremely Fast | No (Broken) |
| SHA-256 | General Hash | Fast | No (Too Fast) |
| PBKDF2 | Key Derivation | Slow (Configurable) | Yes (Acceptable) |
| Bcrypt | Password Hash | Slow (Configurable) | Yes (Excellent) |
Unlike general-purpose hash functions (MD5, SHA-256) designed for speed, bcrypt is deliberately slow. This makes brute-forcing password hashes extremely expensive for attackers.
Where developers use it
Choosing the right cost factor
Aim for a cost factor that takes ~100-250ms on your server. A cost factor of 12 represents 2^12 (4096) iterations, which balances security and performance.
Preventing Rainbow Tables
Bcrypt automatically generates and embeds a unique salt in the output hash string, rendering precomputed hash databases (rainbow tables) useless.
Handling maximum password length
Bcrypt has a maximum input length limit of 72 bytes. Longer passwords are truncated. To handle longer inputs, you can pre-hash with SHA-256 before feeding it to bcrypt.
Frequently asked questions
A typical bcrypt hash looks like $2a$12$R9h/lSpxbKuY9eJJIaMpeO3F6aR2cK.... The $2a$ identifies the algorithm version. The $12$ is the cost factor (rounds). The next 22 characters are the salt, and the remaining 31 characters are the actual cipher digest.
SHA-256 is designed to be extremely fast. Modern GPUs can calculate billions of SHA-256 hashes per second, allowing hackers to quickly crack stolen passwords. Bcrypt is deliberately slow and memory-hard, making GPU-based cracking extremely expensive.
No. Bcrypt is a one-way hashing function and cannot be decrypted. To verify a password, bcrypt extracts the salt and cost factor from the existing hash, hashes the new plain text with those parameters, and compares the resulting strings.
Bcrypt has a strict limit of 72 bytes. Any characters beyond 72 bytes are ignored. To support longer passwords without truncation, developers often pre-hash passwords with SHA-256 and encode them to hex/base64 before running bcrypt.
No. Hashing runs entirely in a background Web Worker on your device. The input never leaves the page, so it's safe to hash file contents, secrets, or anything sensitive.