Should I use bcrypt or Argon2?

Argon2id for new systems: it is the winner of the Password Hashing Competition and is memory-hard, which makes GPU and ASIC cracking far more expensive. bcrypt is still acceptable and very widely supported, so keep it if your stack already uses it.

Why is the hash different every time for the same password?

Each hash uses a new random salt, so the output changes every time. That is intended. To check a password, verify it against the stored hash instead of comparing two freshly generated hashes.

Can a bcrypt or Argon2 hash be decrypted?

No. They are one-way functions. The only way to find the password is to guess candidates and hash each one, which these algorithms make deliberately slow.

What is the 72-byte limit in bcrypt?

bcrypt uses only the first 72 bytes of the password. Anything after that does not affect the hash, so two long passwords sharing their first 72 bytes produce matching hashes. Argon2 has no such limit.

What cost factor should I use for bcrypt?

At least 10, and 12 is a common default. Each increment doubles the work. Choose the highest value that keeps login acceptably fast on your server.

Are $2a$, $2b$ and $2y$ bcrypt hashes compatible?

Yes, for passwords up to 72 bytes they produce the same hash. Most libraries accept all three prefixes, and this tool verifies all of them.

Why does verifying take as long as hashing?

Verifying means hashing the password again with the salt and parameters stored in the hash and comparing the results, so it costs exactly the same work. That is what makes guessing expensive.

Is the password sent to a server?

No. bcrypt and Argon2 run in WebAssembly inside your browser. Nothing you type leaves the page.

Bcrypt & Argon2 Hash Generator and Verifier Online

Hash a password with bcrypt or Argon2, or check one against a stored hash

This password hash generator creates bcrypt hashes (<code>$2b$</code>, cost 4 to 15) and Argon2id, Argon2i and Argon2d hashes in the standard PHC string format, with your own memory, iteration, parallelism, salt and output sizes. Switch to <strong>Verify</strong> to paste a hash from your database, have its algorithm and parameters recognised from the prefix, and test whether a password matches. Each hash takes a fresh random salt and shows how long it took on your device. Hashing runs in WebAssembly in your browser; the password is never uploaded.

How to generate a bcrypt or Argon2 hash

1Choose Hash, then the algorithm: Argon2id for new systems, bcrypt to match an existing one.
2Set the cost: a bcrypt cost factor, or an Argon2 preset such as OWASP 19 MiB, t=2. Adjust memory, iterations and parallelism by hand if you need to match a configuration.
3Type the password and press Hash password. The encoded hash, its parts and the time it took appear below.
4To check a hash, choose Verify, paste the stored hash and the password, and press Verify.

Why passwords need a slow hash

A fast hash such as SHA-256 is the wrong tool for passwords. A single graphics card computes billions of SHA-256 hashes per second, so a leaked table of SHA-256 password hashes can be guessed at that rate. Password hashing functions are designed to be slow and, in Argon2's case, to need a lot of memory, so that each guess costs real time and hardware. A setting that takes a quarter of a second on your server costs an attacker the same quarter of a second for every guess, for every user.

Each hash also carries its own random salt, so two users with the same password get different hashes and precomputed tables are useless. The salt and every parameter are stored inside the hash string, which is why a library can verify a password from the hash alone.

Reading a bcrypt hash

A bcrypt hash such as $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW has four parts: the version 2b, the cost 12 (2¹² = 4,096 rounds of key expansion), a 22-character salt and a 31-character hash, both in bcrypt's own Base64 alphabet. Each step up in cost doubles the time.

$2a$ , $2b$ and $2y$ all compute the same result for passwords up to 72 bytes; the letters record fixes to old implementation bugs. bcrypt reads only the first 72 bytes of a password and ignores the rest, which this tool warns about — a long passphrase, or one in a non-Latin script where a character takes two to four bytes, can reach that limit sooner than you expect.

Argon2id, Argon2i and Argon2d

The PHC string records everything needed to verify: $argon2id$v=19$m=19456,t=2,p=1$<salt>$<hash> means version 1.3, 19,456 KiB of memory, 2 passes and 1 lane, followed by the salt and hash in unpadded Base64.

Argon2id: The hybrid of the two below and the variant RFC 9106 and OWASP recommend for password storage. Use it unless something forces otherwise.
Argon2i: Memory access independent of the password, which resists side-channel attacks but is weaker against GPU cracking with fewer passes.
Argon2d: Memory access depends on the password: strongest against GPUs, but open to side channels. Suited to proof-of-work, not to servers checking logins.

Recommended settings

Argon2id: OWASP recommends 19 MiB of memory with 2 iterations and parallelism 1, or an equivalent trade-off such as 47 MiB with 1 iteration or 12 MiB with 3. RFC 9106 suggests 64 MiB, 3 iterations and 4 lanes where memory allows.
bcrypt: a cost of at least 10; 12 is a common default today. Pick the highest cost your login endpoint can afford — around 250 ms per hash on the server is a reasonable target.
Salt: 16 random bytes. Hash length: 32 bytes is plenty.
Time measured here is on your device, in WebAssembly, which is usually slower than a native library on a server. Benchmark on your production hardware before settling on a cost.

When to use this tool

Use it to create a hash for a seed user or a config file, to check that a hash in your database really matches the password you think it does, or to work out what parameters an existing hash was made with. Your application should hash passwords with its own library at sign-up; it should never send plain passwords to a website to be hashed. To create a strong password to hash in the first place, use the password generator; for keyed signatures rather than password storage, see the HMAC generator.

Frequently asked questions

Should I use bcrypt or Argon2?: Argon2id for new systems: it is the winner of the Password Hashing Competition and is memory-hard, which makes GPU and ASIC cracking far more expensive. bcrypt is still acceptable and very widely supported, so keep it if your stack already uses it.
Why is the hash different every time for the same password?: Each hash uses a new random salt, so the output changes every time. That is intended. To check a password, verify it against the stored hash instead of comparing two freshly generated hashes.
Can a bcrypt or Argon2 hash be decrypted?: No. They are one-way functions. The only way to find the password is to guess candidates and hash each one, which these algorithms make deliberately slow.
What is the 72-byte limit in bcrypt?: bcrypt uses only the first 72 bytes of the password. Anything after that does not affect the hash, so two long passwords sharing their first 72 bytes produce matching hashes. Argon2 has no such limit.
What cost factor should I use for bcrypt?: At least 10, and 12 is a common default. Each increment doubles the work. Choose the highest value that keeps login acceptably fast on your server.
Are $2a$, $2b$ and $2y$ bcrypt hashes compatible?: Yes, for passwords up to 72 bytes they produce the same hash. Most libraries accept all three prefixes, and this tool verifies all of them.
Why does verifying take as long as hashing?: Verifying means hashing the password again with the salt and parameters stored in the hash and comparing the results, so it costs exactly the same work. That is what makes guessing expensive.
Is the password sent to a server?: No. bcrypt and Argon2 run in WebAssembly inside your browser. Nothing you type leaves the page.