Delimiter.live
Encoding & Security Tools Runs on our server Free · no account

Bcrypt Generator and Verifier

The bcrypt tool generates a salted bcrypt hash at a cost factor you choose, and verifies whether a given password matches an existing hash. Bcrypt cannot run in a browser, so this tool runs on our server — use test values, not live credentials.

Use a test password. Unlike the other encoding tools, bcrypt cannot run in a browser, so what you enter is sent to our server to be hashed. It is not stored or logged, but never paste a live credential into any website.

Up to 72 bytes — bcrypt ignores anything beyond that, so longer values are rejected rather than silently truncated.

Each step doubles the work. Production applications typically use 10 to 12.

Runs on our server. Processing happens securely on our server. What you enter is sent to Delimiter.live to produce the result and is not stored in a database.

How to use the Bcrypt Generator and Verifier

  1. To generate: enter a test password, choose a cost factor, and generate the hash.
  2. To verify: paste an existing bcrypt hash and the password you want to check.
  3. Copy the hash into your seed file, fixture or test.

Example

Input
Password: correct-horse, cost 12
Output
$2y$12$… (60 characters, salt included)

Common use cases

  • Creating a hash for a seeded admin account in a development database.
  • Checking that a stored hash matches the password you expect while debugging a login.
  • Comparing how much slower a higher cost factor is on your target hardware.

Limitations and things to watch for

  • This tool runs on our server: the password you enter is sent to Delimiter.live to be hashed. It is not stored or logged, but it is not a browser-only operation. Use a test password, never a live credential.
  • Bcrypt truncates input at 72 bytes. Longer passwords are silently cut, which is a property of the algorithm and a reason to pre-hash long inputs in some designs.
  • Cost is limited to a range of 4 to 12 here, because each increment doubles the work and a high cost on a shared server is an easy way to exhaust CPU. Production applications typically use 10 to 12.
  • A bcrypt hash includes its own random salt, so hashing the same password twice gives different results. That is correct, and verification still works.

Frequently asked questions

Why does the same password produce a different hash each time?
Because bcrypt generates a fresh random salt for every hash and stores it inside the output string. That is what stops precomputed rainbow tables from working, and verification reads the salt back out of the hash.
Is it safe to paste a real password here?
No — use a test value. Unlike the other tools in this category, bcrypt runs on our server, so the password is transmitted. It is not stored or logged, but a credential you send to any third party should be considered exposed.
What cost factor should I use?
Pick the highest value your login endpoint can tolerate, commonly 10 to 12. Each step doubles the computation, so 12 is four times slower than 10 for both you and an attacker.
Is bcrypt still a good choice?
Yes for existing systems. Argon2id is the current recommendation for new designs because it also resists GPU and memory-hardware attacks, but bcrypt at a sensible cost remains far better than any plain hash.

Share this tool