Why does the same password produce a different hash each time?

Bcrypt generates a fresh random salt for every hash and stores the salt and cost inside the encoded result. Different hashes can therefore verify the same password without requiring a separate salt column.

What does the bcrypt cost control?

The cost is a base-two work factor. Increasing it by one approximately doubles the hashing work. Choose a production cost by benchmarking your own authentication infrastructure rather than copying a browser timing.

Why are passwords longer than 72 UTF-8 bytes rejected?

Bcrypt processes only the first 72 bytes. Rejecting longer input prevents two visibly different passwords from being silently treated as the same truncated byte sequence.

Cryptography

Bcrypt Generator & Verifier

Generate salted bcrypt hashes and verify test passwords locally.

What the bcrypt generator and verifier do

Generate creates a random salt, applies bcrypt with the selected cost, and returns the standard modular hash string containing the version, cost, salt, and checksum. Verify reads those parameters from an existing hash and performs bcrypt again before reporting whether the supplied test password matches. Bcrypt is deliberately slow, unlike fast checksum hashes such as MD5 or SHA-256.

Loading tool...

Cost, salt, and the 72-byte boundary

The interface offers browser-safe costs from 8 through 14; higher values can take noticeably longer on slower devices.
Every generated hash uses a new cryptographically random salt, so repeated generation should not return identical strings.
The complete encoded hash should be stored. Its salt and cost are already embedded and are used automatically during verification.
The tool counts UTF-8 bytes rather than JavaScript characters and rejects values over bcrypt’s 72-byte processing limit.

Safe usage boundary

Use this page with synthetic development or QA data. Production password hashing belongs in a trusted server-side authentication flow with rate limiting, secure transport, breach monitoring, and a documented upgrade strategy. A successful comparison proves only that one password matches one encoded hash; it does not assess password strength, account security, or whether the selected cost is suitable for your servers.

Local processing and compatibility

The bcrypt implementation is loaded only after an operation starts, and hashing or comparison runs in this browser. The verifier accepts standard $2a$, $2b$, and $2y$ forms within the cost limit. Clipboard managers, extensions, screen sharing, or an already-compromised device can still expose values, so do not paste real user credentials.

Related developer tools

Continue with Password Generator, HMAC Generator & Verifier, MD5 Hash.

How to Use Bcrypt Generator & Verifier

Enter a synthetic test password and choose a cost appropriate for an interactive browser check.
Generate the hash, then copy the complete encoded value if it is needed in a test fixture.
To verify, enter the candidate password and paste a supported bcrypt hash.
Review the match result and benchmark the final cost in the actual server environment before production use.

Frequently Asked Questions

Why does the same password produce a different hash each time?: Bcrypt generates a fresh random salt for every hash and stores the salt and cost inside the encoded result. Different hashes can therefore verify the same password without requiring a separate salt column.
What does the bcrypt cost control?: The cost is a base-two work factor. Increasing it by one approximately doubles the hashing work. Choose a production cost by benchmarking your own authentication infrastructure rather than copying a browser timing.
Why are passwords longer than 72 UTF-8 bytes rejected?: Bcrypt processes only the first 72 bytes. Rejecting longer input prevents two visibly different passwords from being silently treated as the same truncated byte sequence.

Sources & references

Primary references: OWASP Password Storage Cheat Sheet: bcrypt; bcrypt.js: optimized bcrypt in JavaScript.

Review policy: references and behavior notes are checked whenever the tool implementation changes.