🧂 Bcrypt Hash Generator & Checker

Why Every Developer Eventually Writes a Throwaway bcrypt Script — and How to Stop

It usually starts small. You are seeding a test database with sample users and realize you need realistic password hashes. You know the production code uses bcrypt at cost 10. So you crack open a terminal, spin up a quick Node.js snippet, type require('bcrypt').hash('testPassword1', 10), copy the output, and paste it into your SQL file. Done — until ten minutes later when you need to hash five more test passwords, and you have lost the terminal window.

Or maybe you are debugging an authentication bug. A user claims their password is correct but login keeps failing. You want to know whether the hash in the database was ever generated from the password they think it was. Writing a one-off verification script takes two minutes, but you are already in the middle of something else and switching contexts feels expensive.

These are exactly the moments where a browser-based bcrypt tool pays for itself. No npm install, no switching to a terminal, no temporary scripts cluttering your project — just paste, click, done. The tool above handles both directions: generating fresh hashes at your chosen cost factor, and checking whether a plaintext matches an existing hash.

What bcrypt Actually Does (Without the Hand-Waving)

Bcrypt was designed by Niels Provos and David Mazieres in 1999 and published in a USENIX paper that remains required reading for anyone serious about password storage. Unlike a straight cryptographic hash like SHA-256, bcrypt is deliberately slow. Its core is a modified Blowfish cipher called Eksblowfish — "Eks" stands for Expensive Key Schedule.

The key insight is the cost factor, sometimes called the work factor. At cost 10, bcrypt performs 2¹⁰ (1,024) rounds of key schedule expansion. At cost 11, it does 2,048 rounds. Each increment of 1 doubles the computation time. This is intentional: as hardware gets faster, you raise the cost factor to keep cracking attempts slow. A hash that takes 100 milliseconds to compute takes roughly 10,000 years to brute-force all eight-character passwords, even with modern GPU clusters.

The output format looks like this: $2b$10$<22-char-salt><31-char-hash>. The $2b$ prefix identifies the bcrypt variant. The 10 is the cost factor. The next 22 characters are the salt, encoded in bcrypt's own base-64 alphabet (which uses ./ instead of +/). The remaining 31 characters are the hash itself. Everything you need to verify a password is embedded in this single 60-character string — no separate salt column required.

Why Cost Factor Selection Matters in Practice

New developers often pick cost 12 or 14 because "stronger is better" without thinking about what happens under load. At cost 14, a single bcrypt operation takes roughly 1–2 seconds on modern hardware. If your authentication endpoint has to handle 500 login attempts per second during a flash sale, cost 14 means you need hundreds of dedicated CPU cores just for password hashing. Your database probably cannot even serve 500 sessions per second at that point, so cost 14 is overkill — and a denial-of-service risk if someone hammers your login endpoint.

The widely accepted rule of thumb is to choose the highest cost factor that keeps a hash under 100–250 milliseconds on your production hardware. OWASP currently recommends a minimum of cost 10, with cost 12 as a reasonable default for new systems with adequate resources. The slider in the tool above lets you feel this difference directly: cost 4 is nearly instant in a browser, while cost 12 may take several seconds because JavaScript is single-threaded and cannot parallelize the computation the way native code can.

The 72-Byte Password Limit You Need to Know About

Bcrypt silently truncates passwords to 72 bytes. This is a limitation inherited from the original Blowfish key schedule implementation in OpenBSD, which used a fixed-length key buffer. The practical consequence: passwords longer than 72 bytes are equivalent to their 72-byte prefix. Two passwords that share the same first 72 bytes will produce hashes that verify against each other.

For most users with passwords under 30 characters this is irrelevant. For applications that allow very long passphrases — or that hash values other than human-readable passwords — the truncation is a real concern. The common workaround is to pre-hash the input with SHA-256, then base64-encode that output before passing it to bcrypt. This keeps the bcrypt input at exactly 44 characters regardless of original length. The tool here implements vanilla bcrypt without pre-hashing; it is best suited for typical passwords under 72 bytes.

Reading Hashes Across Languages and Frameworks

One of bcrypt's biggest practical advantages is interoperability. A hash generated by Node.js's bcrypt package, PHP's password_hash(PASSWORD_BCRYPT), Python's bcrypt library, or Go's golang.org/x/crypto/bcrypt will all verify correctly against each other, provided they use the same variant prefix. The only friction point is the legacy $2a$ prefix versus the corrected $2b$ prefix introduced to fix a bug in how non-ASCII characters were handled. Most modern implementations treat them as equivalent for verification purposes, but should generate new hashes as $2b$.

The checker in this tool accepts both $2a$ and $2b$ hashes, so you can paste in hashes from any language's bcrypt library and test them against candidate passwords without leaving your browser. This is particularly useful when debugging cross-service authentication issues or validating that a database migration preserved password hashes correctly.

When Not to Use Bcrypt

Bcrypt is purpose-built for password hashing. It is the wrong tool for encrypting data (it is one-way), generating API tokens (use a CSPRNG), or hashing large files (use SHA-256 or BLAKE3). Its 72-byte input limit and single-threaded nature make it a poor choice for high-throughput scenarios outside of authentication flows.

For new systems choosing a password hashing algorithm today, Argon2id is the current OWASP recommendation. It won the Password Hashing Competition in 2015, resists both GPU and side-channel attacks more effectively than bcrypt, and allows tuning memory usage alongside time cost. That said, bcrypt has a decades-long track record in production systems, excellent library support across every major language, and no known practical vulnerabilities when used correctly. If your stack already uses bcrypt at cost 10 or higher, there is no urgent need to migrate — the security properties are still sound.

Using This Tool Safely

The implementation embedded in this page is pure JavaScript — no WebAssembly, no external requests, no analytics. All computation happens locally in your browser. You can confirm this by checking the network tab in DevTools: no requests fire when you click Generate or Check. The bcrypt algorithm here was cross-validated byte-for-byte against the npm bcrypt package (which wraps the reference C implementation), confirming output identity across passwords, cost factors, and edge cases including empty strings, Unicode characters, and maximum-length 72-byte inputs.

Even so, treat this as a developer utility, not a production secret. Do not use it to hash passwords for a live user database through a shared computer, and do not paste real user credentials into any web tool unnecessarily. For production workflows, use your server-side bcrypt library. This tool is for the moments when you need a hash right now — to seed a fixture file, check a suspicious database entry, or just understand what a cost-10 bcrypt hash looks like before you write the test that generates one properly.