Bcrypt Hash Verifier — OneFreePlace

Candidate & stored hash

Candidate password

0 UTF-8 bytesExact byte comparison

Bcrypt hash

Paste a bcrypt hash. It will be parsed before any expensive work begins.

Ready.

Verification result

Waiting

No verification has been run.

Prefix—

Cost—

Work units—

Prefix—

Cost—

Salt—

Digest—

Rehash policy

Paste a valid hash to evaluate whether it should be upgraded after the next successful login.

Byte identity lab

Bcrypt hashes bytes, not the visual appearance of a password. This diagnostic never changes your input.

Effective UTF-8 bytes (first 72)—

Enter a candidate password to inspect its encoding.

Batch verifier

One row per line: password ⇥ hash

Up to 30 rows. Processing is sequential to keep the browser responsive.

#	Result	Prefix	Cost	Time	Policy
No batch has been verified.

Stored-hash policy scanner

Audit bcrypt metadata without passwords and without performing bcrypt. Paste one hash per line to find weak work factors, legacy prefixes, malformed records and hashes that should be rehashed after a successful login.

Portfolio summary

Valid bcrypt0

Malformed0

Needs rehash0

Strongest cost—

#	Prefix	Cost	Salt	Status
Run an audit to inspect stored hashes.

What verification actually does

Bcrypt verification extracts the stored cost and salt, hashes the candidate password with those exact parameters, then compares the resulting hash. The original password is never decrypted because bcrypt is a one-way password hash.

Rehash after successful login

If a stored hash uses an older work factor or legacy prefix, verify it first. After a successful login, create a new hash using your current policy and replace the stored value. This upgrades security without knowing every user password in advance.

72 bytes, not characters

Only the first 72 UTF-8 bytes are effective in widely compatible bcrypt implementations. Multi-byte characters can reach the boundary much earlier than 72 visible characters. Do not silently normalize or truncate passwords in application UI.

CPU abuse safety

The work factor is embedded in an untrusted hash string. This browser tool refuses active verification above a configurable safety ceiling rather than allowing a malicious cost such as 31 to lock the tab for an impractical amount of time.

Version prefixes

$2b$ is the modern default. $2y$ is common in PHP and is verified with corrected bcrypt behavior. $2a$ is accepted with a compatibility warning. $2x$ marks the historical sign-extension bug and is intentionally rejected.

Privacy

Verification and auditing run locally. Nothing is uploaded, and this tool does not store password history. For production authentication, perform verification in the trusted server runtime and apply rate limits and account-abuse protections.

Node.js example

const ok = await bcrypt.compare(candidate, storedHash);\nif (ok && needsUpgrade(storedHash)) {\n  storedHash = await bcrypt.hash(candidate, 12);\n}

PHP example

if (password_verify($candidate, $storedHash)) {\n  if (password_needs_rehash($storedHash, PASSWORD_BCRYPT, ['cost' => 12])) {\n    $storedHash = password_hash($candidate, PASSWORD_BCRYPT, ['cost' => 12]);\n  }\n}