What the Bcrypt Generator Does
The Bcrypt Generator produces bcrypt password hashes in your browser. Type the password into the input panel, set the cost factor in the options bar (a Rounds number, 4–12, defaulting to 10), and the output panel shows the full 60-character modular crypt format string — for example $2b$10$t1TfS7wsgypmRvxEwyTrreXSKiBEc8LJMcbAICa9bM0Q1NuDSlIIq.
Bcrypt is the right tool for password storage and this tool's siblings in the hash family are the wrong ones — that is worth stating plainly on a page full of hash generators. Plain SHA-256 is fast, and fast lets an attacker test billions of guesses per second against a stolen database. Bcrypt is deliberately slow — each hash takes tunable milliseconds rather than tunable nanoseconds — and embeds a unique random salt, so identical passwords hash differently and precomputed tables are useless. Those two properties, slowness and salt, are what make the difference between a leaked database that is a catastrophe and one that is merely inconvenient.
The tool runs the industry-standard bcryptjs library locally; the password never leaves the page. Each run generates a fresh random salt, so hashing the same password twice produces two different-but-equally-valid strings — that is bcrypt working correctly, not a bug, and the worked example demonstrates it.
How bcrypt Works
Bcrypt (Niels Provos and David Mazières, 1999) is a password hashing function built on the EksBlowfish key schedule. Rather than hashing once, it runs a salted, expensive key-setup loop whose iteration count is the cost factor — the number you set. Each increment of the cost doubles the work: cost 10 is 2¹⁰ iterations, cost 11 is 2¹¹, and so on. That tunable slowness is the design's core idea: as hardware speeds up, you raise the cost factor and the hashes get slower in step, keeping offline guessing expensive forever.
The output string packs every parameter into its 60 characters — this is the modular crypt format, and reading it tells you everything about the hash: $2b$10$ means the bcrypt variant (2b, the corrected 2014 OpenBSD implementation this library uses), the cost factor (10), followed by $ and 22 characters of Base64-encoded 16-byte salt, then 31 characters of Base64-encoded 24-byte hash. The salt and cost travel inside the string, which is why verification needs nothing but the stored hash and the candidate password — no separate salt column, no configuration.
The salt deserves its own sentence because it is the anti-table property. A fresh 16-byte random salt per hash means an attacker cannot precompute anything before knowing your specific database, and two users with the password hunter2 produce entirely different stored strings. Salts are not secrets — they live in the hash itself — because their job is uniqueness, not confidentiality.
Verification is the other half of the design, and it is important to understand what this tool does and does not do: it generates hashes. Verification re-runs bcrypt with the salt and cost from the stored hash and the candidate password — deterministic, hence exact. Comparison is your login code's one-line job.
Choosing the cost factor is the practical decision. The rule of thumb: pick the highest cost that keeps hashing around 100–250 ms on your production hardware. Cost 10 is a reasonable 2026 default for interactive logins; cost 12 is common where login frequency is lower and hardware is modern. The tool caps at 12 to keep the page responsive while demonstrating the real time-cost relationship.
Using the Bcrypt Generator
- Step 1 — Enter the password. Type or paste it into the input panel. What you type stays in the page — nothing is transmitted, nothing is stored, and closing the tab clears it.
- Step 2 — Set the cost factor. The
Rounds field in the options bar, 4–12, default 10. Watch the hashing time grow as you raise it — each increment doubles the work, and feeling that relationship once is worth more than any rule of thumb. - Step 3 — Read the full format string. The 60-character output includes variant, cost, salt, and hash. Store the entire string — every character is needed for verification. Truncating to "just the hash part" is a classic integration bug that breaks logins mysteriously.
- Step 4 — Store it server-side, never client-side. The hash belongs in your users table. It is safe to store — that is the design — but it is produced here for testing, seeding, and education; production hashing belongs in your server's registration flow where the password arrives over TLS.
- Step 5 — Verify the round trip in your stack. Feed the generated hash and the original password to your application's bcrypt-compare function; it should accept. Change one character of the password; it should reject. That two-line test is the entire integration check.
Common Use Cases
Seeding development databases. Generate known-password test users without hardcoding anything sensitive — hash test-password-123 here, put the hash in your seed file, and document the plaintext in the README.
Understanding your stored hashes. Paste-free inspection: the format anatomy (variant, cost, salt, hash) makes your production users table legible — which users got hashed at which cost, and how old the weakest hashes are.
Cost-factor benchmarking. Time hashing at costs 8 through 12 on representative hardware and read the doubling curve directly. The output is the same password hashed at each cost — and the timing is the policy input.
Worked Example
Hash the password my secret password at the default cost 10:
$2b$10$t1TfS7wsgypmRvxEwyTrreXSKiBEc8LJMcbAICa9bM0Q1NuDSlIIq
Read it apart: $2b$ — the bcrypt variant; 10$ — cost 2¹⁰ = 1,024 key-schedule iterations; t1TfS7wsgypmRvxEwyTrre — the 22-character salt (16 bytes, Base64); XSKiBEc8LJMcbAICa9bM0Q1NuDSlIIq — the 31-character hash (24 bytes). Sixty characters total, and every one is needed for verification.
Now the property demonstration: run the same password again. The output is a different 60-character string — fresh salt, fresh hash, equally valid. Both strings verify against my secret password; neither verifies against my secret passwordX. This non-uniqueness is bcrypt's salt doing its job: an attacker comparing two hashes cannot even tell the passwords were the same.
Finally, feel the cost curve: re-hash at Rounds: 12 and notice the computation take roughly four times as long as cost 10 — two doublings. In production that is 80 ms versus 300 ms of login latency; in an attacker's offline crack, four times the cost per guess across billions of guesses.
Tips and Common Mistakes
- Store the whole 60-character string. Variant, cost, salt, hash — all of it. Database columns shorter than 60 characters silently truncate and produce un-verifiable logins. The classic column is
VARCHAR(60) or more. - Do not double-hash. Hashing the bcrypt output again with SHA-256 breaks the format, discards the embedded cost and salt, and adds zero security. Bcrypt's output is the stored artifact; nothing wraps it.
- Verify with the library, not by string comparison. Re-hash-and-compare is subtly wrong (salt differs per run); the compare function reads salt and cost from the stored hash — use it.
Verify with the library, not by string comparison. Re-hash-and-compare-equality is subtly wrong (salt differs per run). The compare function reads the salt from the stored hash and checks the candidate — use it.
- 72-byte password truncation is real. Bcrypt silently truncates at 72 bytes. Passphrases longer than that lose their tail — mostly harmless, but cap the input or pre-hash with SHA-256 before promising "any length" in signup validation.
- Revisit the cost as hardware improves. The cost factor is the design's answer to Moore's law; migrating users by re-hashing on next successful login is the standard incremental path.
- Page-generated hashes are for testing and education. Production registration should hash server-side where the password first arrives. The algorithm and library are the same; the boundary is about where passwords travel, not about the maths.
Frequently Asked Questions
Why two hashes of the same password are different — is that a bug?
The opposite — it is the salt working. Each generation draws a fresh random salt, and the hash includes it, so identical passwords produce different stored strings. Verification still succeeds because the compare function reads the salt from the stored hash before computing. The property an attacker loses is the ability to match hashes against each other or against precomputed tables; the property users keep is their password.What cost factor should I use?
The highest that keeps a login around 100–250 ms on your production hardware — commonly 10 to 12 in 2026. Each increment doubles both user-visible latency and attacker cost per guess. Benchmark on real hardware rather than adopting a number blindly, and plan to revisit upward over the years.What do the $2a$, $2b$, and $2y$ prefixes mean?
Variant history: 2a is the original 1999 designation, 2b the 2014 OpenBSD-corrected variant this tool emits, 2y a PHP-world label that behaves as 2b. All three verify correctly with modern compare functions — the variants differ in edge-case handling, not the algorithm's core.Can I verify a password with this tool?
No — the tool generates hashes only. Verification feeds the stored hash and a candidate password to a bcrypt-compare routine (salt and cost are read from the stored string automatically). Exercise that one-line call in your own tests.How does bcrypt compare to Argon2 and scrypt?
All three are sound; Argon2 and scrypt add memory hardness that prices out GPU crackers more thoroughly, and new systems often choose Argon2id — but bcrypt remains battle-tested for 25+ years, universally available, and the format most developers will meet in existing databases.Related Tools