Hash
Argon2id, bcrypt, scrypt and the usual digests.
Runs entirely in your browser. Nothing is sent anywhere.
They are the work factor, and they exist for exactly one reason: to make guessing expensive. A password hash has to be slow. SHA-256 will hash a password in well under a microsecond, so an attacker holding your database can try billions of guesses a second against it.
Iterations
Each iteration is one more HMAC over the previous output, chained so they cannot be skipped or parallelised. 600,000 iterations means one guess costs 600,000 hashes instead of one. OWASP currently puts the floor at 600,000 for SHA-256 and 210,000 for SHA-512. This is the only knob PBKDF2 has: it buys time, never memory.
Memory
The reason to pick Argon2. Every guess has to allocate and fill this much RAM before it can finish. A GPU has thousands of cores but only a few GB to share between them, so demanding 64 MiB per guess cuts how many can run at once — arithmetic is cheap to parallelise, memory is not. Raise this before anything else.
Iterations (passes)
How many times Argon2 sweeps back over that memory. Memory is the main defence; passes are what you raise once memory is as high as you can afford. Three is the common floor, and doubling it roughly doubles the time at unchanged RAM.
Parallelism (lanes)
How many lanes fill the memory at once. It does not change the total work, only how wide it is spread — set it to the number of cores you are willing to give one hash. It is baked into the output, so a verifier must use the same value.
Cost
A power-of-two exponent: cost 12 means 2¹² = 4,096 rounds of the Blowfish key schedule, and every step up doubles the time. bcrypt has no memory knob — its working set is a fixed 4 KiB, small enough to sit in fast on-chip memory, which is why GPUs still gain more against it than against Argon2 or scrypt. 12 is a reasonable modern default.
Parallelism (p)
How many independent copies of the whole mixing job run. It multiplies CPU time without raising the memory ceiling, so it is the knob for when you want more work but cannot spend more RAM.
Cost N
The number of memory blocks scrypt fills before it starts reading them back in a random order, given as a power of two. It sets both time and memory: the working set is roughly 128 × N × r bytes, so N = 2¹⁵ at r = 8 is about 32 MiB. Each step up doubles both.
Block size (r)
How much data each mixing step touches, in 128-byte units. It is a multiplier on the memory (128 × N × r) and on the size of every read, so raising r makes each access larger and more sequential — friendlier to a CPU with a wide memory bus than to a GPU running thousands of small parallel reads. 8 is the standard value; change N first, r only if you want more memory without more rounds.
Tune it to the slowest hardware that must run it: pick the highest setting where a single hash still takes about 250–500 ms. Then store the parameters with the hash — Argon2 and bcrypt encode them in the output string for you, which is why those outputs start with $argon2id$v=19$m=… and $2a$12$…
Password hashing runs through hash-wasm in a WebAssembly module loaded on demand; the SHA-2 family uses the browser's own crypto and loads nothing. Either way the input never leaves this page. Hashing a real password in a browser is a dev convenience — in production, hash on the server.