">
Cryptographic String & Salt Inspector

Bcrypt Hash Validator Online

A dedicated bcrypt hash validator online and bcrypt hash checker developer utility. Easily check valid bcrypt hash string syntax, test bcrypt encryption string validity, and parse cost factors and salts.

Valid Bcrypt Hash String

Color-Coded Modular Crypt Format Decomposition

$2b$12$LJ3m4om7s/Lq5f.k.lO6Ou4Vq6yN9Z8d6pL6lP5Z6H7J8K9L0M1N2
Prefix (Algorithm): $2b$
Cost Factor: 12 (4,096 iterations)
Salt (22 chars): Valid Radix-64
Checksum (31 chars): Valid Radix-64
Hash Component Parsed Value Length / Specification Status / Diagnostic
Algorithm Identifier $2b$ (OpenBSD Bcrypt) 3 or 4 characters Valid
Cost Factor (Workload) 12 Range: 04 to 31 (2^cost iterations) 4,096 Key Expansion Rounds
Radix-64 Salt LJ3m4om7s/Lq5f.k.lO6Ou Exactly 22 characters (128 bits entropy) 22 / 22 characters
Radix-64 Checksum 4Vq6yN9Z8d6pL6lP5Z6H7J8K9L0M1N2 Exactly 31 characters (184 bits) 31 / 31 characters
Total Hash Length 60 characters Exactly 60 characters standard Standard 60-char length

Complete Guide to Bcrypt Hashes and String Validity Checking

In web application security, storing user passwords securely is the most vital architectural responsibility. Modern authentication frameworks (including Spring Security, Laravel, Django, Ruby on Rails, ASP.NET, and Node.js Passport) rely heavily on the bcrypt hash algorithm designed by Niels Provos and David Mazières in 1999.

With this bcrypt hash validator online and bcrypt hash checker developer utility, developers, system administrators, and security auditors can check valid bcrypt hash string formats, test bcrypt encryption string validity, inspect work factors, and diagnose subtle syntax corruptions that cause authentication lockouts.

Anatomy of the Modular Crypt Format in Bcrypt

A standard bcrypt hash adheres to the Modular Crypt Format (MCF), producing a single ASCII string formatted as:

$[id]$[cost]$[22 character salt][31 character checksum] // Real-World Production Example: $2b$12$LJ3m4om7s/Lq5f.k.lO6Ou4Vq6yN9Z8d6pL6lP5Z6H7J8K9L0M1N2

Let us dissect each of the four components:

  • Identifier ($id$): Specifies the exact bcrypt revision. Valid values are $2$, $2a$, $2x$, $2y$, and $2b$.
  • Cost Factor ($cost$): A two-digit decimal number between 04 and 31 indicating the workload. The algorithm performs 2^cost key expansion iterations. A cost of 10 equals 1,024 rounds; a cost of 12 equals 4,096 rounds.
  • Salt: A 22-character string encoded in modified Radix-64 representing 128 bits (16 bytes) of cryptographically random salt. This guarantees that two identical passwords generate completely different hashes, thwarting precomputed rainbow table attacks.
  • Checksum: A 31-character string encoded in Radix-64 representing 184 bits of output from the Eksblowfish (Expensive Key Schedule Blowfish) cipher encrypting the string "OrpheanBeholderScryDoubt" 64 times.

History of Bcrypt Identifiers: $2a$ vs $2x$ vs $2y$ vs $2b$

One of the most common questions in cryptographic engineering is why so many different identifier prefixes exist:

Identifier Origin / History Status Today Behavioral Notes
$2$ Original OpenBSD release (1999). Obsolete Deprecated due to ambiguity in string termination.
$2a$ Added null-terminator handling (2000). Widely Used Vulnerable in PHP < 5.3.7 to high-bit signed char wraparound bugs.
$2x$ Introduced in PHP 5.3.7 (2011). Legacy Workaround Simulates buggy PHP behavior for backwards compatibility during upgrades.
$2y$ Introduced in PHP 5.3.7 (2011). Standard in PHP Certifies correct signed 8-bit character hashing without bugs.
$2b$ OpenBSD modern revision (2014). Recommended Best Practice Fixes password length wraparound at 256 characters. Default in Go, Python, and Node.js.

How to Choose the Optimal Cost Factor in 2026

The greatest architectural advantage of bcrypt over fast hashes like SHA-256 or MD5 is its configurable work factor. Because computing speed doubles every few years (Moore's Law), hardware brute-force attacks grow faster. With bcrypt, increasing the cost factor by 1 doubles the calculation time without requiring database schema changes:

Cost Factor Total Key Expansion Rounds ($2^{\text{cost}}$) Approximate Hash Time (Modern CPU) Recommended Use Case
101,024 rounds~50 - 80 msLegacy hardware, low-power IoT devices
112,048 rounds~100 - 150 msAcceptable minimum baseline
124,096 rounds~250 - 350 msCurrent Industry Gold Standard (2026)
138,192 rounds~500 - 700 msHigh security banking & government authentication
1416,384 rounds~1,000 - 1,400 msOffline master key derivation (Too slow for interactive web logins)

Validating Bcrypt Hashes Programmatically

Below are standard production routines for validating and verifying bcrypt hashes in key languages:

1. Node.js with `bcrypt` / `bcryptjs`

const bcrypt = require('bcrypt'); const hash = '$2b$12$LJ3m4om7s/Lq5f.k.lO6Ou4Vq6yN9Z8d6pL6lP5Z6H7J8K9L0M1N2'; const candidate = 'SuperSecretPassword123!'; // Fast regular expression syntax check const isBcryptSyntax = /^\$2[aby]\$[0-9]{2}\$[./A-Za-z0-9]{53}$/.test(hash); console.log('Is syntax valid:', isBcryptSyntax); // Constant-time cryptographic verification bcrypt.compare(candidate, hash).then(match => { console.log('Password match:', match); });

2. PHP Native Password Hashing (`password_verify`)

<?php $hash = '$2y$12$LJ3m4om7s/Lq5f.k.lO6Ou4Vq6yN9Z8d6pL6lP5Z6H7J8K9L0M1N2'; // Inspect metadata $info = password_get_info($hash); print_r($info); // Array ( [algo] => 1 [algoName] => bcrypt [options] => Array ( [cost] => 12 ) ) // Verify password against hash if (password_verify('SuperSecretPassword123!', $hash)) { // Check if password needs rehash due to cost increase if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 12])) { // Re-hash and save to DB } }

Why Bcrypt Truncates Passwords at 72 Bytes

An essential technical caveat is that the Blowfish cipher operates on a maximum key length of 72 bytes. Any characters in a plaintext password beyond the 72nd byte are silently ignored by the algorithm.

If a user submits a 100-character passphrase, changing characters between byte 73 and 100 will still allow login because only the first 72 bytes are hashed. To mitigate this limitation in modern applications:

  • Pre-hash long passphrases using SHA-256 or SHA-512 before sending to bcrypt, compressing any length string into a fixed 32-byte or 64-byte digest.
  • Or migrate to modern memory-hard password hashing algorithms such as Argon2id (RFC 9106), which does not have a 72-byte restriction.

Frequently Asked Questions (FAQ)

No. Bcrypt is a one-way cryptographic hash function, not reversible encryption. The original plaintext cannot be decrypted. The only way to find the password is by computing candidate guesses through a dictionary or brute-force search.
Bcrypt uses a custom Radix-64 alphabet: ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz. Notice that period (.) and forward slash (/) represent index values 0 and 1, differing from RFC 4648 standard Base64.
If a single-digit cost factor without a leading zero is specified (e.g. $2a$8$... instead of $2a$08$...), the resulting string will be 59 characters. While some libraries accept this, the canonical standard requires two digits, making the total length 60 characters.