What this compares
Four of these — Argon2id, bcrypt, scrypt, and PBKDF2 — are real password-hashing algorithms: deliberately slow, built to resist offline cracking. The fifth, SHA-256, is a general-purpose fast hash included on purpose, as the cautionary counter-example: it's exactly what a password hash should not be. Click any row for its year introduced, OWASP status, tunable parameters, and a link to a full write-up.
Why memory hardness is the column that matters most
Speed alone is a weak signal — all four real KDFs can be tuned to roughly the same millisecond range for a single hash. What actually differs, and what determines how expensive an attacker's cracking hardware gets, is memory hardness. GPUs and custom ASICs are extremely good at running billions of parallel guesses; what they're not good at is giving every one of those parallel cores its own large chunk of fast memory. PBKDF2 has none of this — the same slowness runs on cheap, massively parallel hardware. bcrypt has a fixed, tiny (~4 KB) footprint that predates the concept of memory hardness entirely. Argon2id and scrypt make memory usage an actual tunable parameter, typically tens of megabytes per hash — expensive to provision at cracking scale in a way 4 KB or 0 KB never is.
Why SHA-256 is on this list at all
Because "just hash it with SHA-256" is one of the most common real mistakes in password storage, and comparing it directly against the four algorithms built for this job makes the gap concrete rather than abstract. SHA-256 itself isn't broken — it's doing exactly what it was designed to do, which is being fast. That speed is precisely what makes it wrong here: a single modern GPU computes on the order of billions of SHA-256 hashes per second, salted or not. See Why SHA-256 Should Not Be Used for Passwords for the full case.
FAQ
Which one should I actually use?
Argon2id for a new system with no special constraints — it's OWASP's current default recommendation. PBKDF2 specifically when FIPS-140 compliance is a hard requirement. bcrypt or scrypt are both still solid choices, particularly if you're already running one of them in production or working in an ecosystem where it's the established standard — see Bcrypt vs Argon2 for a deeper head-to-head between those two specifically.
Where do the numbers in this table come from?
The OWASP status and minimum parameters match OWASP's Password Storage Cheat Sheet, the same reference this site's Password Hash Generator, Password Hash Inspector, and Bcrypt Cost Calculator use for their own defaults and warnings, so a given number reads the same way across every tool here.
Can I generate or verify one of these hashes directly?
Password Hash Generator computes bcrypt, Argon2id/i/d, scrypt, and PBKDF2 hashes with configurable parameters, and Password Hash Inspector decodes an existing hash you already have back into its cost factor or memory/iteration settings. Both run entirely in your browser.