Bcrypt Generator & Verifier

Hash passwords with bcrypt and verify existing hashes. Choose the cost factor (rounds). All processing runs locally — passwords never leave your browser.

Hash a password with bcrypt and verify an existing bcrypt hash against a plaintext candidate — useful for seeding database users in development, debugging an auth flow, or checking that your application's bcrypt implementation produces matching hashes. Adjustable cost factor (rounds) shows how slow each bump makes the hash, which is the entire point of bcrypt's tunable workload. Hashing runs in the browser via the pure-JavaScript bcryptjs library; the password you test is never sent anywhere — exactly what you'd want from a tool you use to hash credentials.

Generate Bcrypt Hash

10Recommended

Verify Password Against Hash

Bcrypt Hash Structure

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
$2a$

Algorithm version

10$

Cost factor (2^10 = 1024 iterations)

salt+hash

22-char salt + 31-char hash (Base64)

Next steps

Hash Generator

Generate MD5, SHA-1, SHA-256, and SHA-512 hashes from any text — MD5/SHA-1 for checksums, SHA-256/512 for integrity.

Password Generator

Create strong, random passwords that are virtually uncrackable.

JWT Decoder

Decode JWT tokens and inspect header, payload, claims, and expiry instantly.

Base64 Converter

Encode or decode Base64 in one click — works with text and files.

View all tools →
Runs right inside your browser tab. No uploads. Your files stay private.

What Is Bcrypt?

Bcrypt is an adaptive password-hashing function designed by Niels Provos and David Mazières in 1999, built around a deliberately expensive variant of the Blowfish key-setup schedule. It was created specifically to make password cracking expensive, in contrast with general-purpose hashes like SHA-256 that are tuned for raw speed.
This tool runs the pure-JavaScript bcryptjs library in your browser. The same library is used on the server side by countless Node.js applications, so a hash you generate here is bit-for-bit interchangeable with one produced by Express, NestJS, or any backend that calls bcrypt.hash. No password ever leaves your tab - bcryptjs runs synchronously on the main thread (or via short scheduled callbacks that yield control to the event loop for the async API) and never makes a network request.
Every bcrypt output is a single self-describing string of the form $2a$10$<22-char-salt><31-char-hash>. The version prefix ($2a$, $2b$, $2y$) declares the algorithm variant, the next field is the log-2 cost factor, and the rest is a custom Base64 encoding (called bcrypt64) of a 16-byte salt followed by a 24-byte derived key. Because everything needed to verify a password is embedded in the string, you only have to store one column in your database.
The cost factor is the only knob that matters for security. Each increment doubles the work: cost 10 means 2^10 = 1024 internal iterations of the EksBlowfish key schedule, cost 12 means 4096, cost 14 means 16384. On a 2024-class laptop, cost 10 takes around 50-80 ms, cost 12 around 200-300 ms, cost 14 well over a second. OWASP's 2024 password storage guidance recommends cost 10 as a floor and increasing it as your hardware gets faster.
Bcrypt has one well-known limitation: passwords are silently truncated at 72 bytes. Anything beyond byte 72 of the UTF-8 encoded password is ignored entirely. For most users this is fine, but if you accept arbitrary-length passphrases you should pre-hash with SHA-256 (or switch to Argon2id, which has no such cap). The verify step here will report a match against the truncated portion, exactly as a real server would.
Salt handling is automatic: bcryptjs calls a CSPRNG (window.crypto.getRandomValues in the browser) to produce 16 fresh random bytes for every call. That means hashing the same password twice yields two completely different output strings, which is exactly what you want - it defeats rainbow tables and prevents identical passwords from being visible as identical hashes in a database leak.
The verifier on this page is a thin wrapper around bcrypt.compare, which re-derives the hash using the salt and cost factor embedded in the candidate string and performs a constant-time comparison of the result. That last detail matters: a naive == comparison would leak timing information about which byte differed, opening up timing attacks against poorly written login endpoints.

Common Use Cases

01

Seeding test users

Generate ready-to-insert bcrypt hashes for fixture passwords in development databases without running a backend.

02

Verifying a leaked hash

Paste a hash from a breach disclosure (your own, ideally) and confirm whether a candidate password produced it.

03

Sizing the cost factor

Time how long different cost values take in your target browser to choose a value that costs ~250 ms on production hardware.

04

Auth library debugging

Cross-check that hashes produced by your Go, Python, or Ruby bcrypt library match bcryptjs output for the same password.

Frequently Asked Questions

OWASP's current guidance is cost 10 as a floor. Aim for a hash time of around 250 ms on your production server - that's typically cost 12 on modern x86 servers and cost 13-14 on Apple Silicon. Higher is fine for low-volume admin logins; lower is acceptable only for non-security workloads.
SHA-256 is designed for speed and is GPU-friendly - a single RTX 4090 can compute billions of SHA-256 hashes per second. Bcrypt deliberately uses 4 KB of internal state and a sequential key schedule that resists GPU and ASIC parallelism, so an attacker pays roughly the same per guess that you pay per legitimate login.
No. Bcrypt is a one-way function. To check a password you re-run the algorithm with the same salt and cost factor (both stored inside the hash string) and compare the output. There is no decrypt operation - cracking means brute-forcing candidates one at a time.
The Blowfish key schedule that bcrypt is built on accepts a maximum 72-byte key, and bcrypt inherits that limit. Bytes beyond position 72 of the UTF-8 encoded password are ignored. If you need unlimited-length passphrases, pre-hash with SHA-256 or migrate to Argon2id.
They are revisions of the algorithm. $2a$ was the original; $2y$ was a PHP fix for a sign-extension bug in 2011; $2b$ is the modern OpenBSD reference. All three produce the same output for ASCII passwords. bcryptjs writes $2a$ by default, which every modern verifier accepts.
No, and it doesn't need to be. Salts only need to be unique per password - they defeat rainbow tables by ensuring an attacker can't precompute hashes ahead of time. Bcrypt embeds the salt in the output exactly so it can be read back during verification.
Each call to bcrypt generates a fresh 16-byte random salt via crypto.getRandomValues, so the input to the underlying key derivation is different every time. This is intentional. Verification doesn't care, because it reads the salt back out of the candidate hash.
On a 2023 MacBook Pro, cost 14 in bcryptjs takes roughly 1.2-1.6 seconds per hash. Cost 15 doubles that. Anything above 14 is rare in production because it noticeably slows logins and amplifies any DoS pressure on your auth endpoint.
All hashing and verification runs in JavaScript in your browser - bcryptjs has no network code. Even so, treat any web tool as untrusted for live production credentials. For real systems, hash on your own server inside a vetted dependency.
Argon2id is the current OWASP top recommendation because it resists GPU attacks more aggressively and has no length limit. Bcrypt remains a perfectly acceptable choice and has wider library support across older runtimes - choose Argon2id for greenfield, stay on bcrypt for compatibility with legacy databases.
Maintained by the WebToolVerse teamLast updated Suggest an edit

Advertisement

What's next?
Hash Generator
Password Generator