Bcrypt Hash Verifier

Use this bcrypt hash verifier to find out whether a candidate password matches a stored hash, free and entirely in your browser. Paste the 60-character hash, type the password you think produced it, and the tool compares the two using the cost factor and salt already embedded in the hash, so you get a plain match or not match answer with no password leaving your device.

How a Bcrypt Hash Verifier Checks a Password

Bcrypt is a password hashing function, unlike a general-purpose hash function, and it is built on the Blowfish cipher, designed for password storage rather than speed. A verifier never reverses anything. It reads the cost and the salt out of the stored hash, runs your plaintext through the same hashing algorithm with those exact settings, and checks whether the hashed output is identical to the stored value. Same inputs, same settings, same result: that is the whole trick.

Match or not match: what the result tells you

A match means the password you typed produces that hash under its embedded settings. Not match means something differs, which could be a typo, a different capitalisation, a hash copied with a missing character, or a hash made by a different system. In the worked example used throughout this page, the password Harbor!Lantern_58 returns a match, Harbor!Lantern_85 (two digits swapped) returns not match, and harbor!lantern_58 (lower case) also returns not match, because bcrypt is case sensitive.

Why a bcrypt hash can't be decrypted

A bcrypt hash is the output of a one-way function, so it is irreversible by design. There is no key and no way to decrypt it, which is why bcrypt belongs to cryptography but is not encryption. A hash can never be reversed into the original password; a verifier can only confirm a guess. The same goes for a fast cryptographic hash such as SHA-256: once hashed, the input is gone and only a comparison remains.

Bcrypt Hash Generator and Verifier: Step-by-Step Use

The page works in two directions. Generate a hash from plaintext and a cost, or paste an existing hash and a password to verify it. Both run client-side, so no data is sent to a server. Need to check a hash comparison? There is a free, no-sign-up tool for exactly that.

1. To create a hash, enter the original text, pick the salt rounds (the cost), and click Generate.
2. To verify, paste the full encoded hash into the hash box.
3. Type the password you want to test into the password box.
4. Click Verify, which is how a bcrypt verify check runs, and read the match or not match badge, along with the parsed version, cost and salt.

Using it as a bcrypt password checker

As a bcrypt password checker it answers one question: does this hashed password belong to this input? Developers use it for testing a fixture, debugging a failed sign-in, and development work where a seed account's hash needs confirming. It is a password checker for diagnosis, not a way to guess strangers' passwords.

Reading a Bcrypt Hash: 60-Character Anatomy

Every bcrypt hash is a single encoded string with four parts joined by $ signs. Here is the hash generated for the worked example at cost 11, split into its pieces: Use the free file checksum comparator to confirm everything looks correct before you rely on it elsewhere.

Joined, that gives $2b$11$DYPbcs4qwQS.Nfu.IkAVBuA26T47BiOlzLlQzAU0t4dd2gpPJ.o9a, exactly 60 characters. Count a pasted hash and you can often spot truncation before verifying at all.

Version prefixes: $2a$, $2b$, $2x$ and $2y$

The prefix names the version of the algorithm. $2a$ is the original widely deployed form, $2b$ is the current corrected form most libraries write today, and $2y$ is the PHP spelling of the same fix. $2x$ marks hashes made by a buggy older implementation. Some legacy systems accept only $2a$, so if verification fails across tools, compare the prefix first.

The salt is embedded: why the same password gives different hashes

Because the salt is embedded in the hash, hashing the same password twice produces different hashes, and both still verify; two bcrypt hashes of one input are expected to differ. This salted hashing defeats any precomputed rainbow table, since every user gets a unique salt. It also means a verifier needs nothing but the candidate and the hash.

Cost Factor and Salt Rounds Behind Every Bcrypt Hash

The cost factor is bcrypt's adaptive cost factor: a dial you can turn up as hardware improves. The number is an exponent, so each increase doubles the computation:

At cost 11 that is \(2^{11} = 2{,}048\) rounds of key setup; at cost 12 it is 4,096. I timed the example password on a laptop CPU to show what that does to latency:

Choosing the work factor for your server

The recommended starting point is 12 rounds, often written as cost factor 12. Always benchmark on the same hardware that handles real sign-ins, because the right work factor is slow enough to make brute-force attacks and dictionary attacks expensive yet fast enough that users never notice. Slower hashing costs the attacker far more than it costs you, which is the whole point of bcrypt's performance trade-off. Paste any existing hash into the page and its parsed cost shows at a glance whether that hash sits below the cost you chose.

Verify Hash Errors: Invalid Hashes and the 72-Byte Limit

When you verify hash input and see not match, check these causes before assuming the password is wrong.

Invalid hash and malformed input

An invalid hash is not 60 characters, lacks a valid prefix, or has a bad cost. A malformed string normally gives a validation error rather than a plain mismatch, so read the message area. Stray spaces, line breaks and a stripped $ are the usual culprits when a hash is copied from a log or a database export.

The 72-byte limit and truncated passwords

Bcrypt reads only the first 72 bytes of a password. This 72-byte limit means longer input is silently truncated by some libraries, while stricter tools show it as rejected. Multi-byte characters use several bytes each, so a long passphrase with accented letters can hit the cap sooner than you expect.

Debugging a Failed Login with a Bcrypt Hash Verifier

Ines Calder is moving a small membership site from PHP to a Python service, and one test user, quill&Ferry-3094 with a capital F, keeps getting rejected at sign-in. She suspects the migration mangled the stored value, so she opens the verifier instead of reading logs.

From the database export she pastes $2y$10$ndyWLUFy6Ut8Tsmb3uwmTewI1l3OQtuA14yk15N7Ba4Q2W9.7VUb, then types Quill&Ferry-3094, the password the user swears they set. The page reports a validation error, not a plain not match. That distinction matters: counting the characters gives 59, one short of the 60 a complete hash needs. The final 6 was dropped when the export wrapped the line.

She re-copies the full value, ending in Ub6, and verifies again. Now the badge reads match. The parsed fields show prefix $2y$ and cost 10, which is PHP's spelling of the corrected $2b$ form, so the hash itself was never the problem. She also tests quill&Ferry-3094 in lower case, and that returns not match, confirming bcrypt is case sensitive and ruling out a loose comparison on the old side.

• Cause found: a 59-character hash in the migrated column, not a wrong password.
• Next action: re-run the import with the column width widened from 59 to 72 characters, then re-verify five sample accounts.
• Follow-up: because cost 10 is below the 12 she wants, she schedules a re-hash for each user's next successful login.

Everything she needed came from reading the verifier's result: the error type, the length, and the parsed version and cost.

Bcrypt Password Checker in a Login Flow

In an application, verification is the last step of the login flow. At sign-up you hash and store only the result; at sign-in the app loads that stored password hash and compares it with what the user typed. Your authentication code accepts the attempt only on a match.

Python example with hashpw and checkpw

import bcrypt

stored = bcrypt.hashpw(b"Harbor!Lantern_58", bcrypt.gensalt(rounds=11))
print(bcrypt.checkpw(b"Harbor!Lantern_58", stored))  # True
print(bcrypt.checkpw(b"Harbor!Lantern_85", stored))  # False

The same two calls exist in Python, Java, PHP and NodeJS: hashpw creates the hash and checkpw verifies it. Use trusted libraries in production, never a hand-rolled implementation.

Migrating to a higher cost with re-hashing

When you raise the cost, there is no need to force resets. On each successful sign-in, re-hash the verified password at the new cost and save it. This re-hashing approach moves every active account forward as part of migrating your settings. The parsed cost shown for each pasted hash tells you which accounts are still below your target and need this treatment.

Bcrypt vs Argon2: Is a Bcrypt Hash Still Secure?

Yes, a bcrypt hash made with a sensible cost remains secure, but OWASP now names Argon2id as the first choice for new systems. Bcrypt needs little memory, so GPU and ASIC hardware can attack it more cheaply than a memory-hard design. Argon2 and scrypt were built around memory hardness; bcrypt was not. Argon2 won the Password Hashing Competition in 2015, which is a large part of why it is favoured today. Keep bcrypt for existing systems, and note that MD5 and plain SHA hashes are never acceptable for passwords.

Using an Online Bcrypt Password Verifier Safely

An online bcrypt password verifier is meant for checking and learning, not for pasting live secrets. Treat it the way you would any password tool, because security habits matter even for a harmless-looking page.

Browser processing and the bcryptjs library

Many browser-based tools, including those built on bcryptjs, process input in your browser, so nothing is uploaded; check that any tool you use says so. Still, prefer test accounts and sample data over real passwords, and close the tab when you finish.

Frequently Asked Questions

How does bcrypt verification work without knowing the original password?

A bcrypt hash embeds its own salt and cost factor in plain text as part of the string (the $2b$10$... prefix). Verification re-runs the exact same bcrypt computation using that embedded salt and cost against the password you supply, then checks whether the resulting hash matches -- it never needs to "decrypt" anything, because bcrypt is a one-way function.

Is it safe to paste a real password into this tool?

The comparison runs entirely in your browser using the audited bcryptjs library -- nothing is transmitted, logged, or stored. That said, treat any tool asking for a real password with healthy caution generally; this one is open about running 100% client-side, and you can confirm that yourself via your browser's network tab (zero requests fire when you click Verify).

Why does it say the hash is invalid?

Bcrypt hashes have a strict format: a version prefix ($2a$, $2b$, $2x$, or $2y$), a two-digit cost factor, and exactly 53 more Base64 characters (in bcrypt's own alphabet) for the salt and digest together. Extra whitespace, a truncated copy-paste, or a hash from a different algorithm entirely (like MD5 or SHA-256) will all fail as "not a valid bcrypt hash."

Can I use this to test a hash generated elsewhere?

Yes -- bcrypt is fully standardized, so a hash produced by any correct implementation (PHP's password_hash, Python's bcrypt library, Node's bcryptjs, Ruby's bcrypt gem) verifies identically here. Use the Bcrypt Generator if you need to create a new hash instead of checking an existing one.

Does the cost factor matter for verification?

You don't need to know or set it -- it's read directly from the hash you paste in, so verification always uses whatever cost factor that specific hash was originally created with, even if it differs from your current default.