Comparison

Bcrypt vs Argon2

Both are deliberately slow password hashing functions with salting built in. Bcrypt is older, available everywhere and tuned by a single cost factor, but silently truncates input beyond 72 bytes. Argon2id is the current recommendation: it is memory-hard, which resists the GPU and custom-hardware attacks bcrypt only partly slows, and it has no length limit.

Bcrypt Generator and Verifier

Create and verify bcrypt password hashes.

Open the tool

A password hashing function has one job that ordinary hashes do not: to be slow. A general-purpose hash such as SHA-256 is designed for speed, which is precisely what an attacker with a stolen database wants. Bcrypt and Argon2 are built to make each guess expensive.

The difference between them is what they make expensive. Bcrypt costs CPU time. Argon2 costs CPU time and memory, and memory is the harder resource for an attacker to parallelise across thousands of GPU cores.

What actually differs

Hardness: bcrypt is CPU-hard; Argon2 is CPU-hard and memory-hard.
Tuning: bcrypt has one cost factor; Argon2 has time, memory and parallelism parameters.
Input limit: bcrypt silently truncates past 72 bytes; Argon2 has no practical limit.
Age and support: bcrypt dates from 1999 and is available everywhere; Argon2 won the Password Hashing Competition in 2015 and needs a reasonably current library.
Variants: Argon2 comes in three — use Argon2id, which combines the resistances of the other two.

Why memory hardness matters

An attacker cracking a stolen database runs the same function billions of times in parallel. GPUs are extremely good at that when each attempt needs only arithmetic — which is bcrypt's situation, though its design already makes it far harder than a plain hash. Argon2 additionally demands a configurable amount of memory per attempt. Memory is expensive to replicate thousands of times over on a GPU or an ASIC, so the attacker's parallelism collapses long before their compute does.

The bcrypt 72-byte trap

Bcrypt ignores everything past 72 bytes of input. With ordinary passwords this never comes up; with passphrases, or with a scheme that concatenates a password and a pepper, it silently discards the end of the input and weakens the hash without any error. The usual mitigation is to pre-hash with SHA-256 and Base64-encode before passing to bcrypt — which works, and is one more thing to get right. Argon2 simply has no such limit.

Do I need to migrate?

Bcrypt at a sensible cost factor is not broken and is still a perfectly defensible choice. There is no emergency. The standard migration path avoids a rewrite entirely: keep verifying against the old hash at login, and when a password verifies successfully, re-hash it with the new function and store that. The store converts itself as people sign in, and no one has to reset anything. If you are choosing for a new system, choose Argon2id.

Tuning either of them

Set the cost from measured time on your own hardware, not from a number in a blog post. Aim for roughly 250 to 500 milliseconds per hash on the machine that will run it — slow enough to be expensive at scale, fast enough that logins feel instant. For Argon2id, start around 19 MiB of memory with two iterations and adjust from there. Re-measure when you change hardware; a cost set on a 2015 server is far too low today.

Frequently asked questions

Is bcrypt broken?

No. It has no practical cryptographic weakness and remains a reasonable choice at a properly set cost factor. Argon2id is better because memory hardness blunts GPU attacks more effectively, not because bcrypt has failed.

Which Argon2 variant should I use?

Argon2id. Argon2d resists GPU attacks but is vulnerable to side-channel analysis; Argon2i is the reverse. Argon2id combines both approaches and is what current guidance, including OWASP, recommends.

What cost factor should I set?

Whatever produces roughly 250 to 500 milliseconds on your own hardware. Measure it rather than copying a number — a cost that was appropriate a decade ago is far too fast now, and the right value differs between a laptop and a production server.

How do I migrate without resetting everyone's password?

Re-hash at login. Verify against the stored hash as usual, and on success hash the plaintext you just verified with the new function and replace the stored value. Over a few months the store migrates itself, and dormant accounts can be forced to reset.

Does bcrypt really ignore long passwords?

Yes, past 72 bytes, and silently. It matters for passphrases and for any scheme that appends a pepper. Pre-hashing with SHA-256 and Base64-encoding before bcrypt is the usual fix; Argon2 has no limit to work around.

Tools used in this guide

All tools →

All guides →

Last reviewed 7 August 2026.