bcrypt Hash Generator

Passwords are hashed in your browser. Nothing leaves this page.

Cost: 10

default 10 · ~150ms · higher cost = slower but stronger

Try a different algorithm

Use the multi-algorithm view

Verify a hash

Compare against an expected value

About the bcrypt Hash Generator

The bcrypt Hash Generator produces password hashes using the Provos & Mazières bcrypt construction (1999) — the OWASP-recommended algorithm for password storage in 2026. Bcrypt embeds a random salt directly in its modular-crypt output and uses an adaptive cost factor that doubles compute time per step, so you can re-tune your security posture as hardware gets faster without changing the algorithm. Cost factor 10 is the OWASP 2026 minimum; this generator supports 4 (development only) through 12. Everything runs in your browser via bcryptjs — passwords never travel to any server, which is essential when you are generating test fixtures or migrating from a legacy hash format.

Updated: May 8, 2026

How to use the bcrypt generator

Paste the password to hash. (For test-fixture generation; never paste real production passwords into any browser tool.)
Set the cost factor (4-12). 10 is the OWASP 2026 minimum for production; each step doubles compute time. Use 4 only for unit tests where you need fast hashing.
Click Generate. The result is the standard modular-crypt format: `$2a$cost
lt;22-char-base64-salt><31-char-base64-hash>` — exactly 60 characters total.
Click Copy for the clipboard, or Compare to paste a candidate password and verify it against the generated hash (uses `bcryptjs.compare` internally).
Performance varies by cost: cost 10 is around 100 ms per hash on baseline hardware; cost 12 is around 400 ms. The page stays responsive during hashing because bcryptjs yields control between rounds.

Common use cases

Development password fixture generation. Seed your test database with known passwords + their bcrypt hashes so integration tests can authenticate as those users.
Migrating from legacy hash formats. If your application stores SHA-256-of-password (or worse, MD5), the migration path is: on next successful login, re-hash with bcrypt and update the stored hash. The generator produces the format your migration code needs to compare against.
Verifying server-side bcrypt output. During backend integration testing, confirm that your server's `bcrypt.hash(password, cost)` output matches what this generator produces for the same input — useful when wiring up a new auth service.
Generating a test password for a stolen-database scenario. Demonstrate to stakeholders why bcrypt makes brute-force expensive: a cost-12 hash takes ~400 ms; an attacker testing 10^9 candidate passwords needs ~12 years on a single core.
Educational comparison. Hash the same password with cost 4, 8, 10, 12 to see how much each cost step actually slows things down. The doubling is striking when measured.

Privacy and security

bcryptjs is a pure-JavaScript bcrypt implementation that runs entirely in your browser. The password, the random salt, and the resulting hash never leave the page. The salt comes from `crypto.getRandomValues` (CSPRNG), so each invocation produces a different output even for the same password — by design. Note: any browser-based hash tool is unsuitable for hashing **real** production passwords; use it for development fixtures, test data, and migration tooling, not for live user credentials.

Tips and pitfalls

Cost factor matters. OWASP 2026 minimum is 10. Cost 12 is a reasonable target for new systems with modern hardware. Each step doubles compute time, so cost 13 is twice as slow as cost 12; pick the highest cost your latency budget tolerates.
72-byte input limit. Bcrypt processes only the first 72 bytes of the password. Passwords longer than 72 bytes are silently truncated (so two passwords sharing the first 72 bytes hash to the same output). To support arbitrarily long passwords, pre-hash with SHA-256 (or use argon2id, which has no length limit).
Salt is embedded in the output. The 22-character salt segment between the cost factor and the hash is the bcrypt-encoded salt. You do not store it separately; the modular-crypt string contains everything needed to verify a candidate password later.
Prefix variants `$2a toolrunner / `$2b toolrunner / `$2x toolrunner / `$2y toolrunner . All four are bcrypt; the differences are historical implementation details (a buffer-overrun bug in the original C implementation, a sign-extension bug in PHP, etc.). All major libraries verify any prefix correctly. New hashes typically use `$2b toolrunner .
bcrypt vs scrypt vs argon2id. Argon2id (the 2015 password-hashing competition winner) is the modern best-of-breed; it is memory-hard, which makes GPU and ASIC attacks more expensive than bcrypt's CPU-bound work. bcrypt remains acceptable per OWASP 2026; argon2id is the preferred choice for new systems if your stack supports it.

Frequently Asked Questions

What cost factor should I use?: OWASP 2026 minimum is 10. For new systems with modern hardware, target 12. Cost 14+ is appropriate for highly sensitive applications (banking, healthcare) where the additional latency is acceptable. Each cost step doubles compute time.
bcrypt vs scrypt vs argon2id?: Argon2id is the modern best-of-breed (2015 password-hashing competition winner) and is preferred for new systems where the language ecosystem supports it. bcrypt remains acceptable per OWASP 2026 and has the most mature library support. scrypt is also memory-hard but is less commonly used in 2026.
What is the 72-byte truncation problem?: Bcrypt only processes the first 72 bytes of the password. A password of length 100 hashes the same way as a password of length 200 if the first 72 bytes are identical. To support longer passwords, pre-hash with a fixed-output hash (SHA-256 → 32 bytes) before passing to bcrypt; or migrate to argon2id, which has no length limit.
Is the salt embedded in the output?: Yes. The bcrypt modular-crypt format is `$2a
lt;cost>
lt;22-char-salt><31-char-hash>` — 60 total characters. The salt is the 22-character base64-encoded segment after the cost factor; you store the full 60-character string in your database, not the salt separately.
How do I verify a candidate password against a stored hash?: Pass both to `bcryptjs.compare(candidate, storedHash)`. The function extracts the cost and salt from the stored hash, runs the same KDF on the candidate, and compares results in constant time. The verifier in this tool does exactly that.
Why is bcrypt slow on purpose?: To make brute-force expensive. A non-slow hash (SHA-256) lets an attacker test billions of candidate passwords per second on a GPU. Bcrypt at cost 12 caps that at roughly 1 candidate per CPU per 400 ms — about 9 orders of magnitude slower. Without slowness there is no defense against offline attacks on a stolen password database.
How do I migrate from SHA-256 password hashes?: Standard pattern: on next successful login, re-hash the plaintext password with bcrypt and update the stored value. Mark accounts that have not logged in for a long time and force a password reset for them. Never decrypt-then-rehash; the SHA-256 hash you stored is one-way.
What is the difference between `$2a toolrunner and `$2b toolrunner prefixes?: Both are bcrypt. The differences are implementation history: `$2a toolrunner was the original; `$2x toolrunner and `$2y toolrunner were emergency patches after a sign-extension bug in PHP's implementation; `$2b toolrunner is the canonical modern prefix. All major bcrypt libraries verify any prefix correctly. New hashes from this generator use `$2a toolrunner for compatibility.