Bcrypt Generator & Verifier
Generate and verify bcrypt password hashes entirely in your browser. No password ever leaves the page.
- Runs in your browser
- No upload, no tracking
- Free forever
How bcrypt works
Bcrypt is a one-way hashing function — you cannot reverse a hash to recover the original password. Verification computes a new hash and compares the result.
How it works
A bcrypt generator hashes a password with the bcrypt algorithm — a deliberately slow, salted, one-way function designed for secure password storage. A cost factor (salt rounds) controls how expensive each hash is, so it stays resistant to brute-force attacks as hardware improves. This tool both generates hashes and verifies a candidate password against an existing one, all locally via bcryptjs so nothing is transmitted. It is built by JusDB, a managed database operations team, alongside its other developer utilities.
- 1
Enter a password
Type the password to hash in the Generate panel. It is masked and never leaves your browser.
- 2
Set the cost factor
Use the salt-rounds slider (4 to 16, default 12). Higher rounds are stronger but slower to compute.
- 3
Generate and copy
Click Generate hash to produce a salted bcrypt hash, then copy it for use in your application.
- 4
Verify a match
In the Verify panel, paste a hash and a password and click Verify to confirm whether they match.
Frequently asked questions
- What is bcrypt?
- Bcrypt is a password hashing algorithm designed to be deliberately slow to deter brute-force attacks. It incorporates a salt to defeat rainbow tables and a cost factor that scales with hardware improvements.
- What are salt rounds?
- Salt rounds (the cost factor) control how computationally intensive the hash is. Each increment roughly doubles the time required. 10–12 rounds is the standard recommendation for most applications.
- Can I reverse a bcrypt hash?
- No. Bcrypt is a one-way function — it is computationally infeasible to derive the original password from a hash. Verification works by re-hashing the candidate password and comparing the result.
- Is this tool safe to use?
- Yes, for testing. Bcrypt generation and verification run entirely in your browser using bcryptjs — no password or hash is ever sent to a server. For production user data, hash on your backend runtime directly.
- What salt rounds does this tool support?
- The slider ranges from 4 (fastest) to 16 (strongest), defaulting to 12. Higher rounds are exponentially slower to compute, so very high values may take noticeable time in the browser.
- How do I verify a password against an existing hash?
- Use the Verify panel: paste the bcrypt hash (it starts with $2a$, $2b$ or $2y$) and the candidate password, then click Verify. The tool re-hashes the password with the embedded salt and reports whether they match.
- What is the difference between bcrypt and a plain SHA hash?
- SHA-256 is fast and general-purpose, which makes it unsuitable for passwords. Bcrypt is deliberately slow, salted per-hash and tunable via a cost factor, so it resists brute-force and rainbow-table attacks — that is why it is used for password storage.
Password hashing with bcrypt, explained
Storing user passwords is a different problem from hashing data for integrity or deduplication. The general-purpose digests behind a hash generator — MD5, SHA-1, SHA-256 — are engineered to be fast. That speed is exactly what makes them dangerous for passwords: an attacker who steals your database can try billions of guesses per second on commodity GPUs. Bcrypt, along with scrypt and Argon2, was built to do the opposite — be deliberately slow and memory-aware so that each guess costs real time and money.
Why a slow, salted hash beats a fast one
A modern GPU can compute many billions of SHA-256 hashes per second, so unsalted fast hashes fall to precomputed rainbow tables and dictionary attacks almost instantly. Bcrypt counters this on two fronts. First, it generates a unique random salt per password and embeds it in the output, so two users with the same password get different hashes and rainbow tables become useless. Second, it runs an expensive key-setup loop (derived from the Blowfish cipher) that no amount of clever precomputation can skip.
The cost factor (work factor) and tuning it over time
The number you set as "salt rounds" is a base-2 cost factor: a value of 12 means 212 = 4,096 key-expansion iterations. Each increment roughly doubles the work, so moving from 10 to 12 makes both legitimate verification and brute-force attacks about four times slower. Because hardware keeps getting faster, the right cost is not fixed — pick the highest value your server can tolerate for a login (commonly tuned so a single hash takes around 100–250 ms) and raise it every few years. A practical migration pattern is to re-hash a user's password at the new cost the next time they log in successfully.
Verifying without storing plaintext, and the 72-byte limit
You never store the password itself — only the bcrypt string, which already contains the algorithm version, the cost, and the salt. To check a login you call the verify function with the candidate password and the stored hash; bcrypt re-derives the hash using the embedded salt and cost and compares the results in constant time. There is no "decrypt" step because there is nothing to decrypt.
One sharp edge: bcrypt only considers the first 72 bytes of input and silently ignores anything beyond that. Long passphrases or pre-hashed inputs can collide on their first 72 bytes, so if you need to support arbitrary-length secrets, pre-hash with SHA-256 and base64-encode before passing to bcrypt — or reach for an algorithm without the limit.
When to choose Argon2 instead
Bcrypt remains a perfectly defensible choice, but Argon2id is the current recommendation from the Password Hashing Competition and OWASP. Unlike bcrypt, Argon2 lets you tune memory cost independently of time cost, which blunts the advantage of GPU and ASIC attackers that have plenty of compute but limited fast memory. If you are starting fresh, prefer Argon2id; if you already run bcrypt at a healthy cost factor, there is no urgency to migrate.
Never reuse a password across a hash and an account. Generate a strong, unique secret with the password generator, then hash it here to see a real bcrypt string — salt, cost factor and all — before wiring it into your application.