Bcrypt Hash Generator / Checker

Welcome to the Bcrypt Hash Generator and Checker — a free online tool that lets you generate cryptographically secure bcrypt password hashes with a configurable cost factor and verify whether a plain-text password matches an existing bcrypt hash. Whether you are seeding a database, debugging a login flow, migrating users between systems, or learning about adaptive password hashing, this tool gives you instant results plus an educational visual breakdown of how bcrypt structures its 60-character hash format.

What is Bcrypt and Why Use It?

Bcrypt is an adaptive password-hashing function based on the Blowfish cipher, designed in 1999 by Niels Provos and David Mazières. Unlike fast cryptographic hashes such as SHA-256 or MD5, bcrypt is intentionally slow and includes a tunable cost factor that can be increased as hardware improves. Every bcrypt hash also incorporates a unique random salt, which prevents attackers from using precomputed rainbow tables. OWASP recommends bcrypt as one of the four acceptable password-hashing algorithms for storing user credentials in modern web applications.

Cost Factor: The Heart of Bcrypt Security

The cost factor (also called work factor or rounds) controls how computationally expensive the hash is. It is logarithmic: each +1 doubles the work. A cost of 12 takes roughly 250 milliseconds on a typical modern CPU; a cost of 14 takes about 1 second. The table below shows estimated compute times for each cost level — pick a value that is fast enough for your login flow but slow enough to frustrate attackers.

Bcrypt Hash Anatomy

Every bcrypt hash is exactly 60 characters long and follows a fixed structure. Understanding each segment makes it much easier to debug login issues or migrate hashes between systems:

The Salt and Digest Encoding

Bcrypt uses a custom base64 alphabet that is similar to standard base64 but uses ./ instead of +/ and does not use padding. This is purely historical and does not affect security. The salt is 16 random bytes, encoded as 22 base64 characters; the digest is 23 bytes, encoded as 31 characters.

Bcrypt Variants Explained

You will encounter several bcrypt prefixes in the wild. All produce hashes of the same structure, but they have distinct origins:

How to Use This Tool

1. Choose mode: Select Generate Hash to create a new bcrypt hash, or Verify Hash to check whether a password matches an existing hash.
2. Enter password: Type the plain-text password into the input field. The byte meter warns you if your password approaches bcrypt's 72-byte limit.
3. Set the cost factor: In Generate mode, drag the slider to choose a cost factor between 4 and 15. The estimated compute time and security rating update in real time.
4. Paste the hash to verify: In Verify mode, paste the existing 60-character bcrypt hash starting with $2a$, $2b$, $2x$, or $2y$.
5. Run and read the result: Click the action button. Generate mode returns the hash with a colour-coded anatomy breakdown; Verify mode shows a large MATCH or NO MATCH indicator with the original cost factor.

The 72-Byte Password Limit

Bcrypt is built on the Blowfish key-setup phase, which only consumes the first 72 bytes of the password. Passwords longer than 72 bytes are silently truncated by older libraries or rejected outright by newer ones. Note that bytes matter, not characters — a single emoji is 4 bytes, and most non-ASCII characters take 2-4 bytes in UTF-8. If your application accepts arbitrarily long passwords, the standard mitigation is to pre-hash the password with SHA-256 and base64-encode the digest before passing it to bcrypt; this produces a fixed 44-byte input that fits comfortably within the limit.

When to Choose Bcrypt vs. Argon2 vs. Scrypt

Modern password-hashing recommendations from OWASP and IETF (RFC 9106) list four acceptable algorithms: Argon2id (preferred for new applications), bcrypt, scrypt, and PBKDF2. Choose bcrypt when:

• You need broad compatibility — every mainstream language has a mature bcrypt library
• You are working with an existing system that already uses bcrypt
• You want a battle-tested algorithm with 25+ years of cryptanalysis
• Memory-hard hashing (Argon2id, scrypt) is impractical for your environment

Choose Argon2id if you are building a new system with no compatibility constraints — it is the modern winner of the Password Hashing Competition and provides resistance against GPU and FPGA attacks that bcrypt cannot match.

Practical Use Cases

For Developers

• Seed development databases with realistic test users without running your full registration flow
• Generate fixture data for integration tests that exercise the login path
• Debug failed logins by verifying the production hash against the password the user reports
• Migrate legacy $2a$ hashes to $2b$ by re-hashing on next login
• Tune the cost factor for your production environment by measuring actual compute time

For Security Engineers

• Verify that a third-party authentication service is producing hashes at the cost factor it claims
• Audit password storage by inspecting hash variant and cost in production samples
• Build training material that shows how bcrypt's anatomy makes it resistant to rainbow tables

For Learners

• Generate the same password twice to see how the salt produces different hashes
• Experiment with different cost factors to feel the doubling effect first-hand
• Verify a known hash to understand how bcrypt extracts the cost and salt before hashing the candidate

Frequently Asked Questions

What cost factor should I use for bcrypt?

OWASP currently recommends a cost factor of at least 10, with 12 being a good modern default that takes about 250 milliseconds on a typical server. Cost is logarithmic, so each +1 doubles the work. Cost 14 is appropriate for high-security applications, while cost 15 is the practical maximum for interactive logins. Never use a cost below 10 in production.

What is the difference between $2a$, $2b$, $2x$, and $2y$?

All four are bcrypt variants distinguished by their prefix. $2a$ is the original revision; $2x$ and $2y$ were emergency PHP fixes for a sign-extension bug discovered in 2011; $2b$ is the modern reference implementation that fixed a wraparound bug in long passwords. Hashes generated with any variant remain verifiable. Modern libraries produce $2b$ by default and you should prefer it for new hashes.

Is the password I enter sent to a server?

The form is processed server-side over HTTPS to perform the bcrypt computation, but neither the password nor the resulting hash is logged or stored — each request is processed and discarded. For absolute paranoia about test passwords, never paste a real production password into any online tool. Use this tool with throwaway test passwords or in a local development environment.

Why does bcrypt have a 72-byte password limit?

Bcrypt is built on the Blowfish key-setup phase, which only consumes the first 72 bytes of input. Passwords longer than 72 bytes are silently truncated by older libraries or rejected by newer ones. To support arbitrarily long passwords, pre-hash with SHA-256 and base64-encode the digest before passing it to bcrypt. This tool warns when your password exceeds the limit.

Can I verify a hash that was generated by another bcrypt library?

Yes. All bcrypt implementations follow the same wire format ($variant$cost$salt+digest, 60 characters total) and produce interoperable hashes. A hash made by Node.js bcrypt, PHP password_hash, Python passlib, Spring Security, or any compliant library will verify correctly here, as long as the variant prefix is recognised.

Why does generating the same password twice give a different hash?

Bcrypt automatically generates a fresh random 16-byte salt for every hash. The salt is mixed into the algorithm and embedded in the output, so two hashes of the same password are virtually never identical. Verification works because checkpw extracts the cost and salt from the stored hash and re-runs bcrypt with those exact parameters before comparing the digest.

Can I retrieve the original password from a bcrypt hash?

No. Bcrypt is a one-way function — there is no decryption operation. The only way to find the original password from a hash is to guess passwords and run them through bcrypt with the same cost and salt until the digests match, which is exactly what attackers do during a brute-force attack. The whole point of bcrypt's adaptive cost is to make those guesses prohibitively expensive.

Does it work on mobile devices?

Yes. The interface is fully responsive and works on smartphones, tablets, and desktops. The mode switch, cost slider, and result panels all adapt to narrow screens.

Additional Resources

• Bcrypt — Wikipedia
• A Future-Adaptable Password Scheme (Provos & Mazières, 1999)
• OWASP Password Storage Cheat Sheet
• RFC 9106 — Argon2 Memory-Hard Function (alternative to bcrypt)