Your files never leave your device. All processing happens locally in your browser.
How do I generate and verify a bcrypt password hash online?
Type a password, pick a cost factor (10–12 is typical), and this tool computes a real bcrypt hash — the 60-character $2 string a login server stores. Switch to Verify to check a password against an existing hash. Everything runs in your browser via WebAssembly; nothing is uploaded.
Real bcrypt via hash-wasm (WebAssembly) — not a PBKDF2 stand-in
Choose a cost factor 4–15; each +1 doubles the work (2^cost rounds)
A fresh 16-byte salt comes from crypto.getRandomValues, embedded in the hash
Verify mode returns a clear MATCH / NO MATCH against any $2a$/$2b$/$2y$ hash
Honest 72-byte truncation warning, plus an Argon2id tab for new systems
What is
bcrypt (adaptive password-hashing function)
bcrypt is a deliberately slow, adaptive password-hashing function built on the Blowfish key schedule (Provos & Mazières, 1999). A tunable cost factor sets how many 2^cost key-setup rounds run, so defenders can keep hashing expensive as hardware improves. Its output is a self-contained 60-character string that stores the version, cost and 16-byte salt alongside the digest, so a server needs only that one value to verify a password. This tool computes it entirely in your browser.
Security & Privacy
Related terms
Argon2idscryptPBKDF2password saltcost factorwork factorBlowfishpassword storageOWASPkey derivation function
Frequently Asked Questions
No. The password, salt and hash are computed entirely in your browser and never leave your device.
This tool is 100% client-side. bcrypt and Argon2id are computed by a WebAssembly module that runs locally, the salt comes from the browser’s crypto.getRandomValues, and there is no server, no upload, no CDN in the crypto path and no telemetry. Nothing is logged or stored — close the tab and it is gone. That said, never paste a real production user’s password into any online tool; use it for building, testing and learning, and do the real hashing on your server.
Use the highest cost your server can tolerate, minimum 10 — pick one that takes roughly 250 ms there.
The cost factor is logarithmic: each +1 doubles the work (2^cost key-setup rounds). OWASP’s floor for bcrypt is a work factor of 10, and 12 is a common modern default; the real rule is to choose the largest value your login server can verify in about 250 ms without hurting user experience. Remember the timing shown here reflects your browser, not your production hardware — benchmark on the server that will actually run it.
bcrypt mixes only the first 72 bytes into its key schedule; anything past that is ignored.
bcrypt derives its Blowfish subkeys from at most 72 bytes of the password, so bytes beyond that are silently dropped — two long passwords sharing the same first 72 bytes produce the same hash. This tool measures the UTF-8 byte length live and warns you before it truncates, matching real bcrypt behaviour so what you hash here verifies the same way on a server. If you must support very long passphrases, pre-hash them (for example base64 of SHA-256) before bcrypt.
For new systems prefer Argon2id (OWASP’s default); bcrypt remains fine for legacy systems at cost 10 or more.
OWASP recommends Argon2id as the first choice for new applications because it is memory-hard, making GPU and ASIC cracking far more expensive than against bcrypt. bcrypt is still a solid, battle-tested option and is appropriate where Argon2 is not available or for existing systems — just configure a cost factor of at least 10. This tool offers an Argon2id tab (memory, iterations and parallelism controls) so you can compare both. Never use fast hashes like md5 or sha256 for passwords.
Detailed Explanation
📖How It Works
What the Bcrypt Hash Generator Does
This tool computes real bcrypt password hashes and verifies passwords against existing hashes, entirely in the browser. bcrypt (Provos & Mazières, USENIX 1999) is a deliberately slow, adaptive password-hashing function built on the Blowfish key schedule (EksBlowfish); a tunable cost factor sets how many 2^cost key-setup rounds run so hashing stays expensive as hardware improves. The output is the canonical 60-character Modular Crypt Format string that embeds the version, cost and 16-byte salt next to the digest, so a login server stores just that one value.
Real bcrypt via the hash-wasm WebAssembly build — not a PBKDF2 stand-in
Hash mode and Verify mode, plus a modern Argon2id alternative tab
Output is the 60-char $2-prefixed string ($version$cost$salt+digest)
Everything runs client-side; the password is never uploaded
⚙️Methodology
Cost Factor, Salt and Hashing
In Hash mode you enter a password and choose a cost factor from 4 to 15 (default 10). The cost is logarithmic, so each +1 doubles the work — a live read-out shows 2^cost rounds and the actual hashing time. A fresh 16-byte (128-bit) salt is drawn from crypto.getRandomValues for every hash, or you can supply your own 32-hex-character salt to reproduce a specific hash. The salt is encoded into the hash string itself (characters 8–29), so there is no separate salt column to manage. Verify mode recomputes bcrypt using the cost and salt parsed out of a pasted hash and reports MATCH or NO MATCH — exactly what a login server does.
Cost factor 4–15; each +1 doubles the time (2^cost key-setup rounds)
Aim for a cost that takes roughly 250 ms on your production server
16-byte salt from crypto.getRandomValues, embedded in the hash
Verify reads version, cost and salt straight from the hash string
Timing shown reflects your browser, not your server hardware
🔧Technical Details
The 72-Byte Limit and $2a / $2b / $2y Variants
bcrypt derives its Blowfish subkeys from at most the first 72 bytes of the password; any bytes beyond that are silently ignored, so two long passwords sharing that prefix collide to the same hash. The tool measures the UTF-8 byte length live, warns before it truncates, and replicates the truncation so a hash made here verifies identically on a server. The version identifiers $2a$, $2b$ and $2y$ differ only in how they handle 255-plus-byte or high-bit inputs; because bcrypt is capped at 72 bytes, they are interchangeable in practice. This engine emits the $2a$ identifier, which every mainstream bcrypt library (Node bcrypt, PHP password_hash, Python passlib, Spring Security) verifies.
Only the first 72 bytes of a password affect the hash
Long-password collisions are real — pre-hash (e.g. SHA-256 → base64) if needed
$2a$, $2b$ and $2y$ are interoperable for practical (≤72-byte) passwords
This tool outputs $2a$; all major bcrypt libraries verify it
⚠️Limitations
Honest Limitations
This tool computes standard hashes correctly, but it is a build-and-test aid, not your authentication stack. The cost factor must be tuned to your own server: the browser timing shown here is only a rough guide. bcrypt is for storing passwords — never use fast hashes (md5, sha1, sha256) for that purpose, and never store plaintext. For new systems OWASP recommends Argon2id (memory-hard) over bcrypt, though bcrypt at cost 10 or more remains appropriate for legacy systems. Real deployments should hash server-side, consider a secret pepper in addition to the per-password salt, and rate-limit login attempts. Never paste a real production user’s password into any online tool.
A build/test aid — do the real hashing on your server
Tune the cost to your server; browser timing is only indicative
Never use md5/sha for passwords, and never store plaintext
Prefer Argon2id for new systems; bcrypt ≥ cost 10 is fine for legacy
Add a pepper, rate-limit logins, and never paste real user passwords
🔒Privacy & Security
Private by Design
Everything happens on your device. bcrypt and Argon2id are computed by a WebAssembly module that runs locally, and the salt comes from the browser’s crypto.getRandomValues — never Math.random. The password, salt and resulting hash are just values in memory: there is no network request, no upload, no logging, no server and no CDN anywhere in the crypto path. Nothing is persisted or added to history, so closing the tab erases everything. The tool works offline once cached, supports dark mode and a mobile-first responsive layout, and has no analytics or telemetry. The only optional network use anywhere on the site is consent-gated ads, which never see your password or hash.
Hashes computed locally via WebAssembly; salt from crypto.getRandomValues
No server, no CDN, no upload, no logging, no telemetry, no account
Nothing persisted — closing the tab erases the password and hash
Works offline once cached; dark-mode and mobile-first
Only optional network use is consent-gated ads that never see your data
Password-hashing functions compared
Function
Type
Tunable cost
Notes
Argon2id
Memory-hard KDF
Memory + time + parallelism
OWASP default for new systems; strongest against GPU/ASIC
bcrypt
Adaptive (Blowfish)
Cost factor (2^cost)
Battle-tested; 72-byte password limit; fine for legacy at cost ≥ 10
scrypt
Memory-hard KDF
CPU + memory
Good memory-hardness; more parameters to tune correctly
PBKDF2
Iterated HMAC
Iteration count
FIPS-approved but not memory-hard; needs very high iteration counts
md5 / sha256
Fast general hash
None
NEVER for passwords — far too fast, trivially brute-forced
For new systems prefer Argon2id; bcrypt remains a solid choice for legacy systems configured with cost 10 or more. Never use fast general-purpose hashes (md5, sha1, sha256) for passwords. Everything in this tool runs locally in the browser; the password is never uploaded. As of July 2026.
