Bcrypt Generator & Verifier

Hash passwords with bcrypt and verify hashes — all client-side, nothing leaves your browser

Password & Options

Try a sample:
10

Higher cost = stronger hash but slower generation. Default 10 is a good balance; 12 is recommended for production.

Bcrypt Hash

Hash appears here

Enter a password and click Generate Hash

About Bcrypt

Bcrypt is the industry-standard password-hashing algorithm. Unlike fast hashing (MD5, SHA-256), bcrypt is deliberately slow: the cost factor (rounds) controls how many iterations are performed, making brute-force attacks computationally expensive. This tool generates bcrypt hashes and verifies passwords against existing hashes — all client-side in your browser, so your passwords never leave your device.

Examples

Hashing a password at cost factor 12

password: "MyS3cr3tP@ss"
rounds:   12
hash:     $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/hq3H8G2mO

A cost factor of 12 is the current production recommendation — it takes ~300 ms on modern hardware, which is fast enough for login flows but slow enough to deter offline cracking.

Verifying a password against a stored hash

password: "MyS3cr3tP@ss"
hash:     $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdBPj/hq3H8G2mO
result:   ✓ Match

bcrypt.compare() re-hashes the input with the salt embedded in the stored hash, then compares. A wrong password produces ✗ No match — no need to store the original password anywhere.

    Examples

    Hash a password at cost factor 10

    Input
    password: P@ssw0rd!
rounds: 10
    Output
    $2b$10$NIS3VD8BGG0kXhEg3c.9XeFSTjjRgESC0W4m/6IgWgk.mg9OpMmli

    A 60-character hash with the `$2b$` algorithm tag, cost 10, a fresh 22-character salt, and a 31-character hash digest. Each call generates a new random salt, so two hashes of the same password are different — both are valid.

    Hash a passphrase at cost factor 10

    Input
    password: correct-horse-battery-staple
rounds: 10
    Output
    $2b$10$ZJiBNW7RxecNyC7cQBR5W.UsOIHacvSJG1h7ciE5gc0M05i4.cBSW

    Long passphrases are far more resistant to brute force than short complex ones — a 28-character passphrase at cost 10 takes orders of magnitude longer to crack than `P@ssw0rd!`.

    Verify the password against the stored hash

    Input
    password: P@ssw0rd!
hash: $2b$10$NIS3VD8BGG0kXhEg3c.9XeFSTjjRgESC0W4m/6IgWgk.mg9OpMmli
    Output
    Password matches

    The Verify tab re-hashes the input with the salt embedded in the stored hash and compares; a wrong password returns 'No match' without ever exposing the stored hash's plaintext.

    About this tool

    Bcrypt is the industry-standard password-hashing algorithm, designed specifically to be slow and resistant to brute-force attacks. Unlike fast hashes such as MD5 or SHA-256, bcrypt incorporates a configurable cost factor that controls how many iterations are performed — making it exponentially harder for an attacker to crack a stolen database of hashes, even with modern GPU hardware.

    The Bcrypt Generator & Verifier gives you two operations in one tool. The Generate tab produces a bcrypt hash from any password, with a slider to choose the cost factor (rounds 4–15). The Verify tab accepts a plain-text password and a stored bcrypt hash and tells you instantly whether they match — exactly the operation a backend runs during login. The embedded salt means every generated hash is unique, even for the same password.

    Everything runs entirely in your browser using the bcryptjs library. No passwords, hashes, or any other input data are transmitted to a server, logged, or stored anywhere.

    How to use

    1. Hash a password

      Enter your password in the Generate tab, adjust the cost factor slider (4–15, default 10), and click Generate Hash. Copy the resulting bcrypt hash with the Copy button.

    2. Verify a password against a stored hash

      Switch to the Verify tab, paste the plain-text password and the stored bcrypt hash, then click Verify Password. Green means they match; red means they do not.

    3. Choose the right cost factor

      Use 10 for development and testing, 12 for production web apps, and 14+ only for scenarios where user-facing latency is not a concern.

    Use cases

    Storing a user's password at signup

    Hash the plaintext password at cost 10–12, store the 60-character hash in the database, and discard the original — the salt is embedded in the hash, so no extra column is needed.

    Verifying a login attempt against a stored hash

    Paste the user-typed password and the stored hash into the Verify tab to confirm they match before letting the user in.

    Auditing password strength without sending data anywhere

    Hash candidate passwords in the browser to time how long each cost factor takes on real hardware, and pick the highest factor your login latency can tolerate.

    Re-hashing older accounts at next login

    Verify against the legacy hash, and if the cost factor is below the current production target (10–12), re-hash with a higher factor and overwrite the stored value.

    Bcrypt hash anatomy

    SegmentMeaning
    $2b$Algorithm version — 2b is the current recommended variant; 2a/2y are also accepted
    10$Cost factor — the number of hashing rounds (2^10 here)
    22 charsBase-64 encoded random salt — generated fresh for every hash
    31 charsBase-64 encoded hash output — the actual password digest

    The full hash is always exactly 60 characters for $2b$/$2a$/$2y$ variants.

    Common mistakes

    Mistake:Treating bcrypt hashes as reversible.

    Fix:Bcrypt is a one-way function — there is no decrypt step. To check a password you re-hash it with the stored hash's salt and compare; losing the hash means losing the password.

    Mistake:Storing the salt separately from the hash.

    Fix:The bcrypt output already embeds the salt in its first 29 characters. Splitting them apart is unnecessary and risks mismatched pairs that fail verification.

    Mistake:Setting the cost factor to 4 for 'fast tests' and shipping it.

    Fix:Cost 4 is only suitable for unit tests that exercise the code path; production logins should use 10–12. The tool exposes 4–15 explicitly so the lower bound is visible during debugging.

    Mistake:Comparing the hashed password to a stored hash with a plain string equality.

    Fix:Use `bcrypt.compare(input, storedHash)` (what the Verify tab runs) so timing-safe comparison is preserved and the cost factor from the stored hash is respected.

    Frequently asked questions

    Related guides

    Hash Generators Explained: MD5 vs SHA-256 vs BCrypt

    What cryptographic hash functions do, which algorithms are still safe, and which to pick for checksums, fingerprints, or passwords — MD5, SHA-1, SHA-256, SHA-512, and BCrypt compared.

    Encryption Tools Explained: AES vs BCrypt vs HMAC

    Three cryptographic primitives developers constantly confuse — reversible encryption (AES), password hashing (BCrypt), and message signing (HMAC). What each one is for, and how to pick correctly.

    References & standards

    Related tools

    AES Encryption

    Encrypt and decrypt text with AES-GCM and a passphrase, fully in your browser. Uses PBKDF2 key derivation and the Web Crypto API — your data and keys never leave your device.

    Basic Auth Generator

    Generate an HTTP Basic Authentication header from a username and password. Produces the Authorization header and ready-to-use curl and fetch snippets. Runs fully client-side.

    BIP39 Mnemonic Generator

    Generate and validate BIP39 seed phrases locally for testing

    Checksum Calculator

    Compute file checksums (SHA-1, SHA-256, SHA-384, SHA-512) in your browser with the Web Crypto API

    CORS Header Validator

    Validate Cross-Origin Resource Sharing headers for security compliance

    CORS Policy Builder

    Build CORS response headers, Nginx directives, and JavaScript fetch examples for safe cross-origin requests and preflight handling