What this tool does
Type a password, pick bcrypt, scrypt, Argon2 (id/i/d), or PBKDF2, and get back a real hash computed with hash-wasm, a WebAssembly build of the same underlying algorithms production libraries use — not a reimplementation. Useful for seeding a database with test users, generating fixtures for a test suite, or checking what a specific set of parameters (cost factor, memory size, iterations) actually produces before you hardcode them server-side.
This is a dev tool, not an auth flow
Hashing happens entirely in your browser — the password never leaves your device. But that's exactly why this shouldn't replace real password hashing in a production signup or login flow: a real user's live password should never pass through a general-purpose web page at all, hashed client-side or not. Do the actual hashing server-side, as part of the signup/login code path, using a maintained library in your backend's language. See Password Hashing Explained for why that distinction matters and how these four algorithms compare.
Default parameters
The pre-filled values for each algorithm come from the current OWASP Password Storage Cheat Sheet: Argon2id at m=19456, t=2, p=1, bcrypt at cost factor 10, scrypt at N=2^17, r=8, p=1, and PBKDF2 at 600,000 (SHA-256), 1,400,000 (SHA-1), or 220,000 (SHA-512) iterations. These are minimums, not ceilings — the heavier a hash is to compute, the harder it is to brute-force offline, so it's reasonable to raise them as far as your server can tolerate.
Why salt is editable
A real system should always use a fresh, random salt per password, which is what this tool does by default. The salt field is editable anyway, because reproducing an exact hash — to confirm a library upgrade produces identical output, or to match a known test vector — needs a fixed salt rather than a random one.
FAQ
I have a hash already, not a password — I want to know what it is
That's Password Hash Inspector: paste an existing bcrypt, Argon2, SHA-256, or MD5 hash and it identifies the format and decodes its cost factor, salt, and parameters, rather than generating a new one.
Why does bcrypt or Argon2 have a "Verify" section but scrypt and PBKDF2 don't?
bcrypt and Argon2 hashes are self-describing — the encoded string embeds the salt and every parameter used to create it, so checking a password against it only needs the password and the hash. scrypt and PBKDF2 have no standard encoded format; the raw hex digest alone doesn't carry its salt or parameters, so verifying one means recomputing it with the same values you used to generate it, using the fields above.
Why does bcrypt ignore part of a long password?
bcrypt only uses the first 72 bytes of the input — anything after that is silently dropped, which is a limitation of the algorithm itself, not this tool. Two passwords that share the same first 72 bytes hash identically under bcrypt.
Is my password sent anywhere?
No — hashing runs entirely in your browser via WebAssembly. Nothing is uploaded, and nothing is logged.
What's the difference between Argon2id, Argon2i, and Argon2d?
Argon2i is optimized to resist side-channel attacks, Argon2d is optimized to resist GPU-cracking attacks, and Argon2id is a hybrid of the two. OWASP recommends Argon2id for password hashing specifically, which is why it's the default here.