bcrypt hash inspector — break down `$2a$10$...` into algorithm / cost / salt / hash

What a bcrypt hash string actually contains

A bcrypt hash like $2b$12$EXRkfkdmXn2gzds2SSitu.MW9.gAVqa9eLS1//RYtYCmB1eLHg6Gm is 60 characters. Parsing it reveals four sections: the algorithm variant (2b), the cost factor (12), the salt (22 characters), and the hash (31 characters). The hash is a one-way transformation — you cannot reverse it to a password. But the full string gives an attacker everything they need to run an offline brute-force or dictionary attack: the Blowfish variant, the work factor, and the salt.

When a database dump leaks and a bcrypt hash surfaces in incident-response analysis, the natural impulse is to inspect its structure. Pasting it into an online bcrypt parser is one way, but doing so sends the salt and cost to a third-party server — information that streamlines offline cracking if the attacker combines it with a weak password list.

Online bcrypt tools and the verification anti-pattern

Searching for ‘bcrypt cost checker’ or ‘bcrypt parser online’ surfaces tools that display the parsed structure. Their server logs capture the hash string, including the salt. That alone is meaningful to an attacker, but the more dangerous pattern is verification: pasting both a plaintext password and its bcrypt hash into a service that advertises ‘check a bcrypt hash.’ Even a test-data hash sourced from a production database is a user password in another guise.

There is a structural asymmetry: the person wanting to check the hash is usually a developer trying to debug an authentication issue. The developer trusts the hash is from a safe environment — but test databases populated from production snapshots carry real users’ hashed credentials, and they get pasted into online verifiers regularly.

Parse-only, no Blowfish computation, nothing leaves the page

This tool parses the bcrypt string structure using regular expressions and string slicing. It performs zero Blowfish key-schedule computation — it cannot verify a password or generate a hash. The only library is the browser’s own string and regex engine. The cost timing estimates are static values calculated from published benchmarks on 2026-era hardware and do not require any network access.

The hash string you paste stays in the JavaScript heap of the browser tab. Open DevTools Network and paste a hash: no request fires. Navigating away clears the input.

Auditing your system’s cost factor before the next breach

Hardware performance doubles roughly every two years in the domains attackers use for cracking (GPUs, FPGAs). bcrypt’s cost factor counteracts this, but only if it is raised to match. OWASP’s 2026 guidance recommends cost ≥ 12 for new bcrypt deployments, with Argon2id as the preferred alternative for greenfield work. Pasting a few sample hashes from your production database into this tool lets you audit what cost your system is actually storing — then you can decide whether a migration is overdue. The standard pattern for existing users is to re-hash on their next successful login rather than forcing a password reset.

EksBlowfishSetup: how bcrypt is internally constructed

bcrypt was introduced by Niels Provos and David Mazières at USENIX 1999 and is built on a deliberately expensive variant of Blowfish key scheduling called EksBlowfishSetup. Standard Blowfish derives its P-array and four S-boxes from the key in a single pass; EksBlowfishSetup interleaves the password and the salt and re-runs that initialisation 2^cost + 1 times. Incrementing cost by one doubles the work — which is why the cost parameter is described as exponential.

After setup, the resulting Blowfish instance encrypts the fixed 24-byte string OrpheanBeholderScryDoubler 64 times in ECB mode, producing a 23-byte digest that is then base64-encoded. The base64 alphabet is bcrypt-specific (./A-Za-z0-9), substituting . and / for the standard + and /. This tool shows that base64-encoded portion as the 31-character hash field; decoding it gives you the raw 23-byte output (excluding the final padding byte of the 24-byte Blowfish block).

2a, 2b, 2x, 2y: version drift and interoperability traps

The bcrypt version prefix (2, 2a, 2b, 2x, 2y) is not just an identifier — each value reflects a specific implementation history. 2 (1999) is the original; 2a (2011) clarified handling of the string terminator; 2x was a bug-compatibility marker for the crypt_blowfish regression in PHP 5.3.7 that mishandled high-bit characters; 2y is the patched version of that fix; 2b (2014) is the OpenBSD implementation’s correction for passwords longer than 255 bytes. Hashes generated with 2x differ from 2a/2b hashes for the same password whenever the password contains bytes ≥ 0x80, so legacy migrations can produce silent authentication failures.

A less-known constraint: bcrypt internally truncates the input to 72 bytes because the underlying Blowfish key schedule rotates through that range. Any 73rd byte and beyond is silently ignored, so password...(arbitrary tail) produces an identical hash regardless of the tail. In passphrase-based systems this becomes a security hole — anyone who knows the first 72 bytes authenticates. The standard mitigation is to pre-hash long inputs with SHA-256 (or HMAC-SHA-256 keyed with the user identifier) and feed the resulting 32 or 64 bytes into bcrypt, which keeps the full input contributing to the final hash. hash-generate is the in-browser way to compute that SHA-256 / SHA-512 pre-digest, and during password-reset rollouts password-strength-check gives you a local zxcvbn-style score before the value ever reaches the bcrypt code path.