RevealTheme logo

Password Hash Generator (PBKDF2)

Generate secure password hashes in your browser using PBKDF2-SHA256. Stronger than MD5 or plain SHA, with adjustable work factor.

How to use this tool

  1. 1

    Type or paste the password you want to hash.

  2. 2

    Optionally set a salt (leave it blank for a secure random one) and choose an iteration count.

  3. 3

    Click Hash. The salted PBKDF2-SHA256 digest is derived entirely in your browser.

How password hashing works — and why a slow hash is a good hash

Storing passwords as plain text, or even as a fast hash like MD5 or SHA-256, is a well-documented way to turn one breach into a catastrophe: attackers who steal your database can test billions of guesses per second against a fast hash. Password hashing functions are deliberately the opposite of fast. PBKDF2 (Password-Based Key Derivation Function 2), the NIST-recommended function this tool implements via the browser's built-in Web Crypto API, takes your password plus a random salt and runs the underlying hash tens or hundreds of thousands of times. That work factor is the whole point — it makes verifying one legitimate login take a fraction of a second (unnoticeable to a user) while making an offline brute-force attack proportionally more expensive. The random salt means two users with the same password get completely different hashes, defeating precomputed 'rainbow table' attacks. PBKDF2 sits in the same family as bcrypt, scrypt, and Argon2 — all 'slow' password hashes — and is built into virtually every platform's crypto library, which is why it's a safe default. This page generates an equivalent-strength hash in your browser for learning, testing, and prototyping; for a real authentication system you should always hash on the server with a vetted library, store the salt and parameters alongside the digest, and never transmit or log the plain password.

Common use cases

  • Learn how salted, iterated password hashing works by watching the output change with the salt and work factor.

  • Generate test hashes to seed a development database without wiring up your real auth code.

  • Produce a reference digest to confirm your server-side PBKDF2 implementation matches for the same inputs.

  • Demonstrate to a team why MD5/SHA-1 password storage is unsafe versus a deliberately slow KDF.

  • Create a one-off credential for a script or prototype where pulling in a full auth library is overkill.

  • Benchmark how iteration count affects hashing time on your hardware to pick a sensible work factor.

Frequently asked questions

Is this real bcrypt?
No — it's PBKDF2-SHA256, which offers comparable security guarantees (salted, slow, tunable) but a different output format. If you specifically need bcrypt's $2b$ format, hash server-side with Node's bcrypt package, PHP's password_hash(), or Python's passlib. The underlying security principle is identical; only the algorithm and format differ.
How many iterations should I use?
OWASP's guidance for PBKDF2-SHA256 has risen to the high hundreds of thousands. The practical rule is 'as high as you can afford while keeping a login verification under ~250ms on your server.' Re-evaluate yearly — as hardware speeds up, the recommended floor rises.
Should I hash passwords in the browser like this?
No — for production, hash on the server. Client-side hashing means the hash itself becomes the effective password (anyone who steals it can replay it), and it locks you into one algorithm forever. This in-browser tool is for learning and testing, not for protecting a live login system.
What is the salt and do I need to store it?
The salt is random data combined with the password before hashing so identical passwords produce different digests. Yes — you store the salt next to the hash (it isn't secret); you need it to verify the password later. Modern hash formats embed the salt and parameters in the output string for exactly this reason, which is why the result here is prefixed with the algorithm, iterations, and salt.
Can I reverse a PBKDF2 hash to recover the password?
No. A hash is one-way by design — there's no decrypt. Verification works by hashing the submitted password with the stored salt and parameters and checking whether the result matches. That's why a forgotten password is reset, never recovered.
Is PBKDF2 still considered strong?
Yes, when configured with a high iteration count it remains NIST- and OWASP-approved, and it's FIPS-validated, which some compliance regimes require. Argon2id is often preferred for brand-new systems because it also resists GPU and memory-hard attacks, but PBKDF2 is a perfectly defensible choice.

Related tools