bcrypt Generator

Create salted bcrypt hashes while checking UTF-8 byte length and a selectable cost factor.

Sample Password0/72 UTF-8 bytes

Cost Factor

bcrypt performs roughly 2^cost key-setup work. A higher value slows both legitimate verification and password guessing.

Generated bcrypt Hash

Generated bcrypt hash will appear here.

Local processing

Hashing runs in your browser with bcryptjs. Yoryantra does not receive the password or resulting hash. Clipboard utilities, extensions, local monitoring, and the device itself remain outside that browser-local privacy boundary.

bcrypt is mainly a compatibility choice in 2026

OWASP currently recommends Argon2id first, then scrypt when Argon2id is unavailable. bcrypt remains relevant for legacy systems and existing password databases. Use sample values here; production password hashing belongs in the trusted authentication environment.

What changes when the cost factor changes

bcrypt stores its cost inside the final hash string. Raising that value makes each password guess more expensive, but it also slows every legitimate login. The right production value is therefore a performance decision measured on the real authentication hardware, not a number copied from a browser benchmark.

The options here stop at 14 because browser-side JavaScript can take a noticeable amount of time at higher costs. That UI limit is not a bcrypt format limit.

Why 72 bytes matters more than 72 characters

Common bcrypt implementations only consume the first 72 password bytes. ASCII usually uses one UTF-8 byte per character, while many other characters use two, three, or four. A visually short Unicode password can therefore reach the bcrypt limit sooner than its character count suggests.

This page blocks longer UTF-8 input rather than hashing a truncated prefix. That makes the limitation visible instead of creating two different-looking passwords that could feed bcrypt the same first 72 bytes.

Salt, cost and hash travel together

A bcrypt string contains a version marker, two-digit cost, salt, and hash data. A fresh random salt means the same password normally produces a different stored string each time. Verification reads the parameters from that stored value and recalculates bcrypt with the candidate password.

$2b$10$...salt-and-hash-data...

Where browser-generated hashes fit

Preparing fixtures for authentication tests.
Checking whether another bcrypt implementation accepts a stored hash format.
Comparing cost-factor latency on the current browser and device.
Learning how a bcrypt record carries its version, cost, salt, and result.

It is not a replacement for server-side password enrollment, rate-limited verification, breached-password screening, account recovery, or secret-management controls.

Current password-storage guidance

OWASP's current Password Storage Cheat Sheet places bcrypt behind Argon2id and scrypt for new designs, while still documenting bcrypt for legacy systems with a work factor of 10 or more and the 72-byte input limit.

Reference: OWASP Password Storage Cheat Sheet