PBKDF2 Hash Generator and Verifier

Derive and verify PBKDF2 hashes with your own salt, iteration count and digest, using Web Crypto - and see why a derived key is not encryption.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Password Show

Hash function

Iterations OWASP currently suggests 600,000 for SHA-256 and 210,000 for SHA-512.

Derived key length (bytes)

Salt (blank for a random 16-byte salt)

Salt is encoded as

PBKDF2 is the weakest of the three, and that is worth saying first

Most pages covering these algorithms present them as three equivalent options. They are not. PBKDF2's only defence is repetition - it does the same cheap operation hundreds of thousands of times. It uses almost no memory, and that is precisely the property GPUs and custom silicon exploit. The same hardware that chokes on Argon2's memory requirement runs PBKDF2 at enormous rates.

So there are good reasons to choose it, and they are all external: a standard or a regulator requires it, you need FIPS validation, or it is simply what your platform provides. A new system with a free hand should use Argon2id.

The iteration count is the entire security parameter

With Argon2 you can trade memory against time. With bcrypt the cost factor covers both. With PBKDF2 there is one lever, so it has to be set high: OWASP currently suggests 600,000 iterations for HMAC-SHA256 and 210,000 for HMAC-SHA512.

The SHA-512 figure being lower is not a typo. SHA-512 uses 64-bit operations, which are comparatively slower on the GPUs attackers use, so each iteration buys more. If you are choosing freshly, SHA-512 is slightly the better option for exactly that reason.

SHA-1 here is not the SHA-1 problem

PBKDF2-HMAC-SHA1 is still widely deployed - WPA2 uses it, and so do many older systems - and it is not broken. The collision attacks that retired SHA-1 for certificates and signatures do not apply to HMAC, which relies on different properties. It needs a higher iteration count, it fails security reviews on sight, and there is no reason to choose it for something new. But finding it in an existing system is not an emergency.

Encoding, and why this page invents one

Argon2 and bcrypt both have a standard string that carries the parameters and salt alongside the hash. PBKDF2 has no such convention - implementations store the iteration count, salt and hash in separate columns, in whatever encoding they chose.

This page writes a PHC-style string, $pbkdf2-sha256$i=600000$salt$hash, so everything needed to verify travels together. It is a sensible convention rather than a standard, which means a hash from your own application probably will not paste in directly - that is a property of PBKDF2, not a limitation here.

Verification is constant-time

Comparing the derived key against the stored one byte by byte, returning as soon as they differ, leaks how many bytes matched. Exploiting that through a browser is a stretch, but a page demonstrating how verification works should show it done properly, so the comparison here runs over the whole value regardless.

Frequently asked questions

Should I migrate away from PBKDF2?

If nothing forces you to use it, yes - to Argon2id. The usual path is to re-hash on next successful login and keep the old hash until then. If a standard requires PBKDF2, raise the iteration count to current guidance instead and revisit it periodically.

My application's hash won't verify here.

Most likely an encoding difference rather than a wrong password. PBKDF2 has no standard string format, so check how your system stores the salt - hex, base64 or raw - and whether the iteration count matches.

How long should a salt be?

16 bytes of cryptographic randomness, unique per password. It is not secret and does not need protecting - it exists to make identical passwords hash differently and to defeat precomputed tables.

Why is 600,000 iterations so slow in the browser?

Because it is meant to be. That cost is the whole protection. If it feels slow here, remember an attacker is paying it for every guess - and that they are paying it on much faster hardware, which is why the number has to be so large.

Is anything uploaded?

No. PBKDF2 is built into the browser's Web Crypto, so this page needs no library at all and makes no request.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.