UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

bcrypt Generator & Verifier

Hash passwords with bcrypt (cost 8–14) and verify hashes in-browser.

About bcrypt Generator & Verifier

bcrypt is the industry-standard algorithm for hashing passwords before storing them in databases. Unlike MD5 or SHA-1, bcrypt is intentionally slow and includes a configurable cost factor that makes brute-force attacks exponentially harder as hardware improves. This tool runs entirely in your browser using bcryptjs — your passwords never leave your device. Use the Generate tab to hash a password at cost factors 8 (fast, ~10ms) through 14 (slow, ~1.5s). The Verify tab checks whether a plaintext password matches a known hash, useful when debugging authentication flows or auditing stored credentials. A timing readout shows exactly how long each hash took so you can tune the cost for your application's performance budget.

Why use bcrypt Generator & Verifier

Runs entirely in-browser

Runs entirely in-browser — your plaintext passwords are never transmitted to any server.

Adjustable cost factor lets

Adjustable cost factor lets you benchmark the right security vs. performance tradeoff for your stack.

Instant verify tab removes

Instant verify tab removes the need to spin up a local Node.js script just to check a hash.

Benchmark timing readout helps

Benchmark timing readout helps you justify cost factor choices in security reviews.

Uses bcryptjs

Uses bcryptjs, the same library deployed in millions of production Node.js applications.

Runs entirely in-browser

Runs entirely in-browser — your plaintext passwords are never transmitted to any server and there is no network request on hash or verify.

How to use bcrypt Generator & Verifier

  1. Select the Generate tab, enter your password, and adjust the cost factor slider (10 is the industry default).
  2. Click Hash Password — the tool shows a live timer and displays the generated hash plus how many milliseconds it took.
  3. Copy the hash with the Copy Hash button for use in your application or database.
  4. Switch to the Verify tab, enter the original password and the stored hash, then click Verify.
  5. A green badge confirms a match; red confirms a mismatch — useful for debugging authentication issues.
  6. Open the Generate tab and type or paste the password you want to hash into the password field.
  7. Drag the cost-factor slider — 10 is the OWASP default, 12 is a common production target, 14 is for high-security applications.

When to use bcrypt Generator & Verifier

  • Testing password hashing logic before deploying an authentication feature.
  • Auditing or debugging stored bcrypt hashes in a database.
  • Generating test password hashes for seeding a development database.
  • Learning bcrypt cost factor tradeoffs before tuning a production system.
  • Quickly verifying that a password reset flow produces correct hashes.
  • Testing password hashing logic before deploying an authentication feature to staging or production.

Examples

Hashing a user password at cost 12

Input: Plaintext: correct horse battery staple Cost factor: 12

Output: $2a$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy Elapsed: ~340ms on a modern laptop

Verifying a stored hash against the original password

Input: Plaintext: correct horse battery staple Hash: $2a$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Output: Match — green badge confirms the plaintext produced this hash.

Detecting a wrong password during authentication debugging

Input: Plaintext: incorrect-guess Hash: $2a$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

Output: Mismatch — red badge; the candidate password did not produce this hash.

Benchmarking your machine for cost selection

Input: Plaintext: bench-test Cost factor: 14

Output: Hash generated in ~1500ms — too slow for live login on this hardware; choose cost 12 instead for a ~100ms target.

Tips

  • Cost factor 10 is the OWASP minimum — raise to 12 if your server can spare the CPU without impacting login latency, and aim for around 100ms per hash.
  • Use the Show/Hide toggle to confirm you typed the password correctly before hashing — a typo wastes a slow round and produces a hash that will never verify.
  • The benchmark time shown is wallclock time in your browser tab — on a server, actual time may differ based on CPU, so always measure on production-equivalent hardware before locking in a cost factor.
  • When migrating from a faster algorithm, double-hash on next login: verify the legacy hash, then re-hash the plaintext with bcrypt and store the new value silently.
  • Pre-hash long passwords with SHA-256 before bcrypt if you allow inputs longer than 72 bytes — bcrypt silently truncates, which can produce surprising collisions in long passphrases.
  • Store only the bcrypt string in your database; do not store the cost factor separately because it is already embedded inside the hash and will be used automatically on verify.

Frequently Asked Questions

What is bcrypt and why is it better than SHA-256 for passwords?▾
bcrypt is a password-hashing function designed to be slow and adaptive. SHA-256 is fast by design, which makes it easy to brute-force billions of guesses per second with modern GPUs. bcrypt forces each guess to be computationally expensive via its cost factor, dramatically slowing attackers even with dedicated hardware.
What cost factor should I use in production?▾
OWASP recommends a cost factor of at least 10, targeting around 100ms per hash on your production server. If your hardware is faster, increase the cost so hashing still takes ~100ms. Never go below 10 for user-facing authentication.
Is it safe to use this tool for real passwords?▾
Yes — the tool runs entirely in your browser using bcryptjs and makes no network requests. Nothing leaves your device. That said, avoid testing production credentials anywhere other than your own secured systems.
Why does the same password produce a different hash each time?▾
bcrypt automatically generates a random 16-byte salt on each call and embeds it in the output hash. This means two hashes of the same password will differ, but the verify function can still check them because the salt is stored inside the hash string.
What does the $2a$ prefix in a bcrypt hash mean?▾
The $2a$ (or $2b$) prefix identifies the bcrypt algorithm version. The number after the next $, like $10$, is the cost factor. The remaining 53 characters encode the salt and the hash together.
Can I use bcrypt for hashing non-password data like tokens?▾
Technically yes, but bcrypt is typically overkill for tokens. For API tokens, HMAC-SHA256 or Argon2 (designed for general key derivation) are more appropriate. bcrypt shines specifically for user passwords.

Explore the category

Hash Generator Generate SHA-256, SHA-1, MD5 hashes PGP Encrypt / Decrypt Encrypt, decrypt, generate PGP key pairs, and sign/verify messages in-browser with OpenPGP.js. File Hash Multi (MD5, SHA-1, SHA-256, SHA-512) Compute MD5, SHA-1, SHA-256, and SHA-512 of any file in your browser JavaScript Minifier Minify JavaScript by removing comments, trimming whitespace, and outputting cleaner code instantly in your browser. User Agent Parser Parse user-agent strings into browser, engine, OS, and device details. URL Parser Parse URLs into protocol, host, path, query parameters, and hash parts.
How Bcrypt Hashes Passwords (And Why Cost Factor Matters) Bcrypt is the password-hashing standard most modern apps still rely on. Here's how the Blowfish-based KDF works, why the cost factor matters Mar 2026 · 9 min Argon2 vs Bcrypt vs Scrypt: Which Password Hash Should You Use? Modern password hashing has three serious contenders. We compare Argon2, bcrypt, and scrypt on memory hardness, GPU resistance, ecosystem su May 2026 · 9 min Hashing Algorithms Explained: MD5, SHA-256, bcrypt — When to Use Which MD5 and bcrypt are both called hashing algorithms, but they serve completely different purposes. This guide explains what makes a hash funct Jan 2026 · 10 min

Glossary

Cost factor
The 'work factor' in bcrypt, controlling how many internal iterations are performed. A cost of N means 2^N rounds; increasing by 1 doubles the time and therefore doubles the brute-force cost for an attacker.
Salt
A random value mixed into the hash input so that two identical passwords produce different hashes. bcrypt uses a 16-byte salt that it generates automatically and stores inside the resulting hash string.
Rainbow table
A precomputed lookup table of hashes for common passwords. Salting defeats rainbow tables because attackers would need a separate table per unique salt — economically infeasible for billions of users.
Hash vs encryption
Hashing is a one-way function: you cannot derive the input from the output. Encryption is reversible with a key. Passwords should be hashed (irreversible), not encrypted, so a database breach does not expose plaintext.
KDF (Key Derivation Function)
An algorithm that turns a low-entropy input (like a password) into a strong cryptographic key. bcrypt, scrypt, Argon2, and PBKDF2 are all password-oriented KDFs designed to be slow.
Modular Crypt Format
The $algorithm$cost$saltAndHash string layout used by bcrypt and other Unix password schemes, originally documented in the Linux crypt(3) manual.
Pepper
A secret value (separate from the per-row salt) that is mixed into every password hash, stored only in application config rather than the database. Adds defense-in-depth against database-only breaches.