PBKDF2 Hash Generator

Generate PBKDF2 password hashes with configurable iterations, key length, and hash algorithm.

Salt (hex) -
Derived Key (hex) -
Base64 -

What is PBKDF2?

PBKDF2 (Password-Based Key Derivation Function 2) is a key derivation function that applies a pseudorandom function (such as HMAC-SHA512) many times to derive a cryptographic key from a password. Because the same password always produces the same key for a given salt, it is widely used to store password verifiers, and it is standardised and recommended by NIST (National Institute of Standards and Technology) in SP 800-132.

PBKDF2 is "iterated": the underlying HMAC is computed again and again, each time feeding the previous result forward. The iteration count is the primary security knob. Every extra iteration multiplies the work an attacker must do per guess, so raising the count directly increases the cost of brute-forcing a stolen hash. A per-user random salt ensures that two users with the same password still get different hashes, which defeats precomputed rainbow tables.

This tool uses the Web Crypto API's built-in PBKDF2 implementation, which is native and hardware-accelerated in modern browsers. Everything — password, salt, and derived key — stays on your device; nothing is uploaded.

Key properties

  • Iterated HMAC — security scales with the iteration count, which is the main defence against brute force.
  • Salted — a fresh random salt is generated for every run, so identical passwords never share a digest.
  • Configurable — choose SHA-256, SHA-384, or SHA-512 as the underlying hash, plus the derived key length.
  • Deterministic for fixed inputs — with the same password, salt, algorithm, and iterations, PBKDF2 always returns the same key, which is what makes verification possible.
  • Standardised — specified as RFC 8018 / PKCS #5 and approved by NIST, so it is available in virtually every language and platform.
  • CPU-hard, not memory-hard — unlike bcrypt and Argon2, PBKDF2 is comparatively cheap to accelerate on GPUs and ASICs.

Choosing an iteration count

Underlying hash Suggested minimum Notes
PBKDF2-HMAC-SHA256600,000OWASP reference figure
PBKDF2-HMAC-SHA384~210,000fewer iterations for equal cost
PBKDF2-HMAC-SHA512~210,000fewer iterations for equal cost

Guidance evolves as hardware gets faster. Treat these as floors rather than fixed targets, and re-tune to a delay your users can tolerate.

How to Use

  1. Enter Password — Type or paste the password you want to hash. Click "Example" for a sample.
  2. Configure Parameters — Select the hash algorithm (SHA-256, SHA-384, or SHA-512), set iterations (default 600,000), and choose key length and salt length.
  3. Generate — Click "Generate Hash" to compute the PBKDF2 hash using the Web Crypto API.
  4. Copy Results — The generated hash, salt, derived key, and Base64 representation are all available for copying.

Output format and verification

The main output is a single self-describing string that bundles every parameter needed to check the password later:

pbkdf2:{algorithm}:{iterations}:{salt_base64}:{key_base64}

For example, a SHA-512 hash with 600,000 iterations looks like this (truncated for readability):

pbkdf2:SHA512:600000:q1R0h3...==:k9Pz2m...=

Because the algorithm, iteration count, and salt are embedded in the string, verification is straightforward: parse the fields, re-run PBKDF2 with the same password and parameters, and compare the derived key. The Details panel also shows the salt as hex, the derived key as hex, and the derived key as Base64.

Note that the salt is randomly generated on every run, so pressing Generate twice on the same password produces two different strings. That is expected and desirable — store the whole string with the account so you can verify it later.

Frequently Asked Questions

What is the recommended number of iterations?

OWASP guidance puts the floor at around 600,000 iterations for PBKDF2-HMAC-SHA256. Because SHA-384 and SHA-512 do more work per iteration, roughly 210,000 iterations achieve a comparable cost. Treat these as minimums and tune upward for the hardware your users have.

How is PBKDF2 different from bcrypt or Argon2?

PBKDF2 is CPU-hard only, so it is relatively cheap to accelerate on GPUs and dedicated hardware. bcrypt is also CPU-hard but designed for password storage, and Argon2 is the most modern: it is both CPU-hard and memory-hard, which makes large-scale parallel cracking much more expensive. PBKDF2 remains attractive because it is NIST-approved and universally available.

What hash format is used?

The output is pbkdf2:{algorithm}:{iterations}:{salt_base64}:{key_base64}. It carries the algorithm, iteration count, and salt alongside the derived key, so a verifier needs only this one string and the original password to check it.

Why does the same password give a different hash each time?

A fresh random salt is generated for every run. The salt is different, so the derived key is different. This is the intended behaviour of PBKDF2 and the reason salts exist: it prevents attackers from reusing precomputed tables across accounts.

What key length should I choose?

A 32-byte (256-bit) derived key is a sensible default and matches the security of a 256-bit hash. Longer keys are supported, but they do not make the password harder to guess — the password entropy and iteration count dominate the security of the scheme.

Should I use PBKDF2 for new applications?

If you are starting fresh and your platform supports it, a modern memory-hard function such as Argon2id is usually the better default. PBKDF2 remains an excellent, well-understood choice when interoperability, FIPS compliance, or library availability matter.

Can PBKDF2 hashes be reversed?

No. PBKDF2 is a one-way function. Given a stored hash you can only guess candidate passwords and recompute, which is exactly why the iteration count must be high enough to make each guess expensive.

Is my password ever uploaded?

No. PBKDF2 is computed entirely in your browser with the Web Crypto API. The password and the derived key never leave your device.