PBKDF2 Password Hash

Hash or verify with configurable iterations — NIST-approved and runs locally via the Web Crypto API. Nothing leaves your device.

Result

Password

Preset

Salt

Use a random salt (16+ bytes recommended).

600,000 iterations selected (Encoded output).

What is PBKDF2 Key Derivation?

Derive strong encryption keys or verify passwords by repeatedly hashing — this key-stretching technique is called "PBKDF2". Runs locally via Web Crypto API.

PBKDF2 (Password-Based Key Derivation Function 2) is a standardized key derivation function defined in RFC 8018 — the NIST-approved, widely supported way to turn a password into a cryptographic key or a stored password hash. It applies a pseudorandom function (like HMAC) to a password along with a salt, repeating the process many times to produce a derived key; thousands of iterations stretch weak human passwords into strong keys and slow offline brute-force attacks. Use this tool to derive keys with configurable iteration counts, or to verify an existing PBKDF2 hash. Derivation runs locally in your browser via the Web Crypto API, so your password never leaves your device.

Iterative strengthening — by repeating the hash operation thousands of times, PBKDF2 makes brute-force attacks computationally expensive.

NIST approved — recommended by NIST SP 800-132 for password-based key derivation.

Hardware-accelerated — uses the Web Crypto API in browsers, leveraging CPU-native instructions for fast iteration.

Self-describing hash strings — Hash mode can output a single encoded string ($pbkdf2$sha256$iterations=600000,len=32$...) that packs every parameter and the salt, so Verify mode can check it later with just the password.

Configurable — you choose the hash algorithm (SHA-256/SHA-384/SHA-512), iteration count, salt, and output length.

Zero-Server Tool Data Guarantee

All hashing and verification happens locally in your browser using the Web Crypto API. Your password and salt are never sent to any server.

How to Use

Hash or Verify

Use Hash to generate a PBKDF2 key, or Verify to inspect and test an existing encoded PBKDF2 hash string.

Apply the OWASP Preset

The default preset uses 600,000 iterations (OWASP's 2026 recommendation). Choose Custom to set the iteration count, PRF hash, and key length manually.

Generate or enter a salt

Use the Generate button for a cryptographically random 16-byte salt, or paste your own. The salt is required and must be stored with the hash.

Extract the Key

The derived key is calculated in your browser. Copy it as an Encoded string (recommended — includes parameters and salt), or as hex/base64 for use in your security implementations.

Inspect Parsed Params

In Verify mode, paste an encoded PBKDF2 hash to see its parsed hash, iterations, len, and salt before checking for a match.

Common Use Cases

Password Storage

Derive a storage-safe hash from a user password with a per-user salt and high iteration count.

Encryption Key Derivation

Turn a passphrase into an AES-256 key for encrypting files, backups, or database fields.

Legacy WPA2 Authentication

WPA2 derives its session key from the passphrase with PBKDF2 (4096 iterations) — an example of PBKDF2 in the wild, but one that shows why low iteration counts age badly. WPA3/SAE uses a different key-exchange KDF.

Multi-Factor Key Derivation

Derive application-specific keys from a master password combined with a device-specific salt.

Implementation Examples

JavaScriptBrowser (Web Crypto API)

async function pbkdf2(password, salt, iterations = 600000) {
    const enc = new TextEncoder();
    const keyMaterial = await crypto.subtle.importKey(
        'raw', enc.encode(password),
        { name: 'PBKDF2' }, false, ['deriveBits']
    );
    const bits = await crypto.subtle.deriveBits(
        { name: 'PBKDF2', hash: 'SHA-256', salt: enc.encode(salt), iterations },
        keyMaterial, 256
    );
    return Array.from(new Uint8Array(bits))
        .map(b => b.toString(16).padStart(2, '0')).join('');
}

PBKDF2 vs Bcrypt vs Scrypt

Feature	PBKDF2	Bcrypt	Scrypt
Memory hardness	None	Low (4KB)	High (configurable)
GPU/ASIC resistance	Low	Moderate	High
NIST approved?	Yes	No (but widely used)	No (RFC 7914)
Hardware acceleration	Yes (Web Crypto)	No (software only)	No (software only)
Configurable hash	Yes (any HMAC hash)	No (Blowfish only)	No (Salsa20/8)
Best for	FIPS/compliance needs	Web apps	High-security / crypto

Production Best Practices & Security

Use at least 600,000 iterations with SHA-256 — this is the current OWASP recommendation for password hashing, and the tool's default (OWASP preset). Why:Each iteration adds a small time delay. By performing hundreds of thousands of iterations, you make it so that an attacker must spend a significant amount of time and energy for every single password they try to guess.

Always use a unique, random salt — use the Generate button or provide at least 16 bytes of cryptographic randomness yourself. Why:Salts ensure that identical passwords result in different hashes. This prevents attackers from using "Rainbow Tables" — pre-calculated lists of hashes for billions of common passwords.

Use HMAC-SHA-256 as the default — it's fast, secure, and well-supported across all platforms. Why:SHA-256 is a modern, cryptographic hash function without known practical collisions, providing a solid foundation for key derivation.

Store the encoded string, not just the key — copy the Encoded output, which embeds the hash, iterations, key length, and salt, so you can verify the password later without remembering parameters. Why:The derived key alone cannot be re-verified without its parameters and salt.

Choose dkLen based on your use case — 32 bytes for most key derivation; 64 bytes for high-security applications. Why:The length should match the requirement of the algorithm you're using. For example, AES-256 requires exactly a 32-byte (256-bit) key.

Don't use PBKDF2 for new high-security projects — consider Argon2 or scrypt for better GPU/ASIC resistance. Why:PBKDF2 only uses CPU time. Attackers can use massive arrays of GPUs or specialized ASIC chips to try millions of passwords in parallel. Argon2 and Scrypt also use memory, which is much harder and more expensive for attackers to scale.

Migrate old PBKDF2 hashes — if you're using fewer than 100,000 iterations, increase the count on next login. Why:As computer hardware gets faster, old iteration counts become easy to crack. Periodically increasing the "work factor" is necessary to maintain security over time.

Frequently Asked Questions

For most new projects in 2026, use Argon2id. It is memory-hard (64 MB per hash), making GPU and ASIC cracking far more expensive than Bcrypt or PBKDF2.

Bcrypt is a strong, widely compatible alternative supported by virtually every language and framework. Use it if Argon2 is not available in your stack.

PBKDF2 is the only option if you need FIPS 140-2 compliance or Web Crypto API support (hardware-accelerated in browsers). Its weakness is lack of memory-hardness — an attacker can parallelize millions of derivations on a single GPU.

Use 600,000+ iterations for PBKDF2-SHA256, cost 12-14 for Bcrypt, or m=65536/t=3/p=4 for Argon2id.

The Web Crypto API provides PBKDF2 as a native browser primitive. The iterative hashing is performed by your browser's underlying cryptographic library (such as Windows CNG or Apple CommonCrypto) rather than a JavaScript implementation.

This gives you hardware acceleration via SHA-NI CPU instructions when available, constant-time operations to prevent timing side-channel attacks, and audited, FIPS-validated code.

A JavaScript-based PBKDF2 implementation would be 3-5x slower and potentially vulnerable to timing leaks that a native implementation avoids.

As of 2026, OWASP recommends 600,000 iterations for PBKDF2-HMAC-SHA256. For higher security margins, 1,000,000+ iterations is reasonable for sensitive applications.

The tool defaults to the OWASP preset (600,000 iterations). You can adjust it in the number field by choosing Custom. The right count depends on your hardware and latency requirements — a good target is roughly 100-200ms verification time on your production servers.

For mobile or browser-based use, you may need fewer iterations to maintain acceptable responsiveness.

Switch to the Verify tab and paste an encoded PBKDF2 hash — the format this tool outputs: $pbkdf2$sha256$iterations=600000,len=32$<salt>$<key>. The tool parses the hash algorithm, iteration count, key length, and salt from the string and displays them, then recomputes PBKDF2 with your password and compares the result in constant time.

Because the encoded string embeds every parameter, you only need the string and the candidate password — no separate parameter storage.

Yes. PBKDF2 key derivation and verification run entirely in your browser using the Web Crypto API — your passwords never leave your device.

The browser's native implementation uses SHA-NI hardware acceleration for the iterative HMAC computation, which also provides constant-time execution resistant to timing side-channels.

The output can be copied as an Encoded string (includes the hash, iterations, key length, and salt — recommended for later verification), or as hex/base64 for raw-key workflows. No input data is sent to any server.