Bcrypt Argon2 Validator

What is a password hash?

Storing a user's actual password in a database is dangerous — anyone who breaches that database gets every password in plain text. A password hash is a one-way scrambled version of the password: it's computationally cheap to check that a password matches a hash, but effectively impossible to reverse the hash back into the original password. Bcrypt and Argon2id are two well-tested hashing algorithms built specifically for passwords, deliberately slow so brute-forcing them is expensive.

How to use Bcrypt Argon2 Validator

1. Choose Hash to create a new hash, or Verify to check a password against an existing hash.
2. In Hash mode: enter a password, pick bcrypt or Argon2id, adjust the cost parameters if needed, and click Hash password.
3. In Verify mode: enter the password and paste the existing hash, then click Verify to see whether they match.
4. Click Copy to copy the generated hash.

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.