How to Generate and Verify a Bcrypt Password Hash

You’re seeding a test database with a handful of user accounts, or you’ve inherited a script that stores bcrypt hashes and you need to check whether a given password actually matches a hash sitting in a .env file. Either way, you need a bcrypt hash right now, and running up a local Node script just to call bcrypt.hash() feels like overkill for a five-second task.

The other option — pasting a real or real-ish password into some random “bcrypt generator” site — is exactly the kind of thing security-conscious developers are supposed to avoid, and for good reason. You have no idea what that site logs.

What generating and verifying a bcrypt hash actually involves

Bcrypt takes a plaintext password and a “cost factor” (also called work factor or rounds) and produces a salted hash designed to be deliberately slow to compute — that slowness is the point, since it makes brute-forcing stolen hashes much more expensive. A higher cost factor means more computation per hash, which is more secure but also slower, so most frameworks default to something in the 10–12 range as a balance.

Verifying works the other way: given a plaintext password and an existing hash, bcrypt re-derives the hash using the salt embedded in the original and checks whether it matches — you never “decrypt” a bcrypt hash back into the original password, because that’s not how it works.

Why people get stuck here

• No local environment handy. Not every situation has Node, Python, or a package manager ready to go for a one-off hash.
• Cost factor confusion. Picking a cost factor that’s too low weakens security; picking one that’s absurdly high can make login checks noticeably slow in production.
• Verifying against a stored hash. Debugging “why won’t this password work” often means manually checking whether a plaintext password actually matches a specific stored hash, which needs the same bcrypt implementation to test against.
• Privacy concerns. Testing with a real user’s password (even a test account’s) on an unfamiliar server is a bad habit that’s easy to fall into when you’re in a hurry.

What a good bcrypt tool looks like

Runs the actual bcrypt algorithm, not a lookalike

A hash generator that produces something bcrypt-shaped but doesn’t match a real bcrypt implementation is useless for testing against your actual application.

Adjustable cost factor

You should be able to set the cost factor explicitly, since different applications and frameworks default to different values, and testing needs to match what’s actually in production.

Processes everything locally

Password hashing tools are exactly the kind of thing that shouldn’t be sending your input to a server — the whole point is testing something sensitive without creating a new place it could leak from.

Common mistakes to avoid

• Testing with a real production password instead of a throwaway test value, even on a tool that claims to run locally.
• Assuming a bcrypt hash can be “decoded” back to the original password — it can only be verified against a guess, never reversed.
• Using a cost factor far below your application’s default when testing, which can make a broken check look like it’s working simply because the hash comparison is trivially fast either way.
• Forgetting that bcrypt hashes are salted per-hash, so hashing the same password twice with the same cost factor produces two different-looking hashes — that’s expected, not a bug.

How to do it with the Bcrypt Hash Generator

Online Tool Store’s Bcrypt Hash Generator runs the hashing entirely in your browser, so nothing you type gets sent anywhere.

1. Enter the password you want to hash and set your desired cost factor.
2. Generate the hash and copy it for seeding a database or test fixture.
3. Switch to verify mode, paste in a password and an existing hash, and check whether they match.
4. Adjust the cost factor and repeat if you’re testing performance trade-offs.

Because it’s all local computation, it’s safe to use even with test credentials you’d rather not send to a third-party server.

Frequently asked questions

Can I recover the original password from a bcrypt hash?

No. Bcrypt is a one-way hash function — there’s no decryption step. Verification works by re-hashing a candidate password with the same salt and comparing the result, not by reversing the hash.

What cost factor should I use?

Most modern frameworks default to somewhere between 10 and 12, which balances security against login response time. Higher values are more secure but slower; check what your specific application or library defaults to and match it for realistic testing.

Why do two hashes of the same password look completely different?

Bcrypt generates a random salt for every hash it creates, even for the identical password and cost factor, which is intentional — it prevents attackers from using precomputed tables against a database of hashes.

Final thought

Bcrypt hashing isn’t something to reinvent or approximate — for real application code, always use your language’s actual bcrypt library. A browser-based generator like this earns its keep for the in-between moments: seeding test data, debugging a login mismatch, or sanity-checking a cost factor before you commit to it in production.

Try the free Bcrypt Hash Generator