Password Hash Generator
Runs entirely in your browser — nothing is uploaded. Even so, never paste a password you actually use: generate hashes for test fixtures, seeds and demos, not for live credentials.
Verify a hash
How it works
Type a password, pick an algorithm, tune its cost parameters, and get the hash string you would store in a database, plus how many milliseconds it took on your machine. That timing is the number that actually decides how hard the hash is to crack.
Four algorithms, one purpose. These are password hashing functions, deliberately slow, and they are not the same thing as the general-purpose digests (MD5, SHA-256) in the Hash Generator on this site. A GPU chews through billions of SHA-256 guesses per second, so a plain digest of a password is no protection at all; these four are engineered to resist exactly that. • bcrypt: the pragmatic default since 1999, still fine. A cost factor from 4 to 16 sets the work, and each step doubles the time. OWASP suggests 10 or more; 12 is a common production value. Output is the familiar self-contained `$2b$12$…` string. • Argon2id: winner of the 2015 Password Hashing Competition and today's first recommendation. Unlike bcrypt it is memory-hard, so you tune memory (KiB), iterations and parallelism until an attacker's GPU runs out of RAM rather than just clock cycles. • scrypt: the other memory-hard option, widely used in cryptocurrency and older systems. Cost N is a power of two; r and p control block size and parallelism. • PBKDF2-SHA256: the oldest and weakest of the four, but the one mandated by many compliance regimes (FIPS). It is not memory-hard, so it leans entirely on iteration count, and OWASP's 2023 figure is 600,000.
Every hash is randomly salted, so hashing the same password twice gives two different strings. That is correct and expected, and it is what stops attackers precomputing rainbow tables.
Verify takes a bcrypt or Argon2 hash and a candidate password and tells you whether they match. Only those two formats can be verified from the hash alone, because only they embed their parameters and salt in the string. scrypt and PBKDF2 have no standard encoded form, so this tool returns their hash and salt separately and you must store the parameters yourself.
Everything runs inside your browser tab with no network request, including the WebAssembly implementations of bcrypt and Argon2. That said, treat any web tool as untrusted for live credentials: use this for test fixtures, database seeds, demos and learning, and let your application's own library hash real user passwords.
Frequently Asked Questions
Which password hashing algorithm should I use?
- Argon2id, if your language has a maintained binding, because it is memory-hard and the current OWASP first choice. bcrypt is a perfectly respectable second and is available everywhere; use cost 10–12. Pick PBKDF2 only when a compliance regime (FIPS) requires it, and then use at least 600,000 iterations.
What bcrypt cost factor should I choose?
- High enough that hashing takes roughly 250–500 ms on your production hardware, the usual latency budget for a login. The timing shown after each hash lets you calibrate: raise the cost until you reach that range. Each +1 doubles the work, so cost 12 is four times slower than cost 10.
Why is the hash different every time I hash the same password?
- Because a fresh random salt is generated for each hash. That is exactly what you want: identical passwords produce different stored hashes, so an attacker cannot spot repeated passwords or use precomputed rainbow tables. Verification still works, because the salt is embedded in the bcrypt or Argon2 string.
Can I verify a bcrypt hash here?
- Yes. Paste the hash and the candidate password into the Verify section. It works for bcrypt ($2a$/$2b$/$2y$) and Argon2 ($argon2id$ and friends), because those strings carry their algorithm, parameters and salt. scrypt and PBKDF2 hashes cannot be verified from the hash alone, since their parameters live outside the string.
Is bcrypt's 72-byte limit a problem?
- Rarely, but know about it: bcrypt silently ignores anything past the first 72 bytes of a password, so very long passphrases are effectively truncated. If you accept long passphrases, or pre-hash passwords with HMAC before bcrypt, keep it in mind. Argon2id and scrypt have no such limit.
Is it safe to type a real password here?
- Better not to. The hashing runs entirely in your browser and this page makes no network request, which you can confirm in DevTools → Network, but the honest advice for any online hashing tool is to keep credentials you actually use out of it. Use this for test data, seeds and learning, and let your backend library hash real passwords.
How is this different from the Hash Generator tool?
- Speed, and it is the whole point. The Hash Generator produces fast general-purpose digests (MD5, SHA-1, SHA-256, BLAKE) for checksums and integrity, which is the wrong tool for passwords precisely because a GPU tries billions per second. This tool implements slow, salted, tunable key-derivation functions built to resist that.
How long an offline attack takes, by algorithm and password
Time for a single high-end GPU (RTX 4090 class) to exhaust the whole keyspace (halve it for the average case). The point is the contrast: the same password is trivial under a fast digest and hopeless under a tuned KDF. Cracking is embarrassingly parallel, so divide by the number of GPUs an attacker rents.
| Password | SHA-256 (unsalted) | bcrypt cost 10 | bcrypt cost 12 | Argon2id (19 MiB, t=2) |
|---|---|---|---|---|
| password123 (in every wordlist) | instant | instant | instant | instant |
| 8 chars, lowercase only | 2 seconds | 3 days | 12 days | 3 months |
| 8 chars, mixed case + digits | 3 minutes | 35 years | 140 years | 1,400 years |
| 10 chars, mixed case + digits | 8 days | > 100,000 years | > 400,000 years | millions of years |
| 12 chars, full ASCII | 8 years | astronomical | astronomical | astronomical |
| 4 random words (diceware) | 1 year | > 1 million years | astronomical | astronomical |
Order-of-magnitude figures, not predictions: rates assume ~2×10¹⁰ SHA-256/s, ~2×10⁵ bcrypt-cost-10/s and ~3×10³ Argon2id/s on one modern GPU, from published Hashcat benchmarks. Two caveats that matter more than the exact numbers: a password appearing in a breach list falls instantly whatever the algorithm, and these are offline times, assuming the attacker already stole your database.
Password hashing algorithms compared
All four are salted and tunable. "Memory-hard" means an attacker needs RAM per guess, which is what blunts GPU and ASIC cracking.
| Algorithm | Year | Memory-hard | Self-contained string | Recommended settings |
|---|---|---|---|---|
| Argon2id | 2015 | Yes | Yes ($argon2id$…) | 19 MiB memory, 2 iterations, parallelism 1 (OWASP minimum) |
| scrypt | 2009 | Yes | No | N = 2^17, r = 8, p = 1 (OWASP minimum) |
| bcrypt | 1999 | No | Yes ($2b$…) | Cost factor 10 or more; 72-byte password limit |
| PBKDF2-SHA256 | 2000 | No | No | 600,000 iterations (OWASP 2023); use only when FIPS-required |
| MD5 / SHA-256 (plain) | 1992 / 2001 | No | No | Never for passwords: billions of guesses per second on a GPU |
Settings follow the OWASP Password Storage Cheat Sheet. Tune upward until hashing takes 250–500 ms on your own production hardware.