Bcrypt Argon2 Validator
Hash and verify passwords with bcrypt or Argon2id, with adjustable cost parameters.
Password
Higher cost = exponentially slower to brute-force, and slower to hash. OWASP suggests tuning for ~250ms+ per hash on your production hardware.
Hash
Check a password against a hash
Result
How bcrypt's cost factor works
Bcrypt runs its internal key-stretching routine 2^cost times before producing a hash. Cost 10 means 1,024 rounds; cost 12 means 4,096 rounds — every single increment doubles the work an attacker's brute-force loop has to repeat per guess:
| Cost factor | Rounds (2^cost) |
|---|---|
| 10 | 1,024 |
| 11 | 2,048 |
| 12 | 4,096 |
This tool hashes and verifies entirely with self-hosted implementations — bcrypt.js for bcrypt, and a WebAssembly build of Argon2 for Argon2id — no server call, no network request, ever.
Argon2id's three cost parameters (RFC 9106)
Unlike bcrypt's single cost factor, Argon2 tunes three independent knobs: memory cost (how much RAM each hash attempt must allocate — this is what makes Argon2 expensive to attack with GPUs/ASICs, which have comparatively little fast memory per core), time cost (iteration count), and parallelism (thread count). This tool defaults to 19 MiB / 2 iterations / 1 thread, RFC 9106's baseline for memory-constrained environments; increase memory cost first if you need more headroom, since that's Argon2's primary defense.
Frequently asked questions
Why does the cost factor matter?
Bcrypt's cost factor sets the number of key-stretching rounds as 2^cost — cost 10 means 1,024 rounds, cost 12 means 4,096 rounds. Each +1 doubles the work an attacker needs to brute-force a single guess, which is why bcrypt stays resistant even as hardware gets faster.
Is my password sent to any server?
No. Hashing and verification run entirely in your browser using self-hosted bcrypt and Argon2id (WebAssembly) implementations; nothing is ever transmitted or logged.
Does this support Argon2?
Yes. Argon2id is fully supported for hashing and verification, with editable memory cost, time cost and parallelism parameters per RFC 9106.
What cost factor should I use?
OWASP recommends a cost factor that takes at least ~250ms per hash on your production hardware — commonly 10 to 12 for typical servers in 2026. Higher is safer but slower; test on your actual hardware.