bcrypt Hash Generator

Generate hash

Higher = slower & more secure. 12 is a good default.

Every so often you have a bcrypt hash from an old backup and a plaintext password, and you need to know whether they match. Or you have a password and want the hash that a given cost factor would produce. This tool does both: type a password and it generates a fresh hash, paste a hash and a candidate and it tells you whether verification succeeds — using the same constant-time compare as a production login check.

Generate or verify bcrypt

  1. 1

    Pick a mode

    Generate a new hash from a password, or verify a password against an existing `$2a$` / `$2b$` / `$2y$` hash.

  2. 2

    For generate: enter plaintext and cost

    Cost 4-14; 10-12 is normal. A 16-byte random salt is created for each hash.

  3. 3

    For verify: paste hash and plaintext

    The tool extracts the salt and cost from the hash and re-hashes the plaintext with the same parameters.

  4. 4

    Read the result

    Generate mode copies the 60-character hash; verify mode returns a green match or red mismatch.

Verify mode internals

Given a stored hash like:

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6

The verifier:

  1. Parses version (2b), cost (12), salt (first 22 chars after cost) and digest (last 31 chars).
  2. Re-runs bcrypt on the candidate plaintext with the extracted salt and cost.
  3. Compares the resulting digest to the original using constant-time comparison.

A successful compare yields true; any difference yields false.

Constant-time comparison

Comparing two strings with a naive == returns as soon as a byte differs — a timing side channel that can leak the hash digit by digit over enough samples. Production password checks (and this tool) use a constant-time compare that always examines every byte, so the decision time does not depend on how many leading bytes match.

Common diagnostic cases

Symptom Likely cause
Verification fails, you are sure of the password Trailing whitespace or BOM in the input. Strip both.
Verification fails, version 2y Some libraries dislike 2y; it is valid and compatible. Re-hash with 2b going forward.
Hash too short / malformed Not a bcrypt hash. MD5 is 32 hex chars, SHA-1 is 40, bcrypt is 60 with $ delimiters.
Cost mismatch warning Stored cost is below your policy minimum. Re-hash on next successful login.

Rehashing on login

Best practice: when a user logs in successfully, check if the stored hash has a cost lower than your current policy. If so, re-hash the password at the new cost and update the database. Within a few months you upgrade the whole user base without asking anyone to change their password.

What the tool does not do

  • Bulk verification — Built for one hash at a time.
  • Crack or brute force — Dictionary or rainbow-table attacks are intentionally out of scope.
  • Retrieve the plaintext — bcrypt is one-way; if you have forgotten the password, the only path is reset.

Frequently Asked Questions

No. The hashing and verification happen in your browser. Neither the plaintext nor the hash leave the page.

The salt is randomly generated per hash. That is the whole point — two users with the same password get different hashes, defeating rainbow tables.

Yes, that is exactly what verify mode does: paste the hash you have, paste a candidate password, the tool confirms or denies a match.

Yes. All modern variants interoperate — the digest is compatible across versions; only the tag differs. Some old $2$ hashes from 2000-era systems may need a library with explicit legacy support.

Related Tools