Generate WordPress-compatible password hashes (phpass) and verify existing hashes directly in your browser.
{{ hash }}Enter a password to generate a WordPress hash.
| {{ __t('info_algorithm') }} | {{ hashInfo.algorithm }} |
| {{ __t('info_iterations') }} | {{ hashInfo.iterations }} |
| {{ __t('info_salt') }} | {{ hashInfo.salt }} |
| {{ __t('info_valid_format') }} | {{ hashInfo.valid ? '✓' : '✗' }} |
WordPress uses the phpass (PHPass) library to hash passwords. It employs iterated MD5 hashing with a random salt. The resulting hashes are prefixed with $P$ (or $H$) and are 34 characters long. These hashes are stored in the wp_users table in the user_pass column. While MD5 alone is considered insecure, the many iterations provide additional protection against brute-force attacks.
The phpass algorithm first generates a random 8-character salt. The hash starts with the prefix $P$, followed by a character indicating the iteration count (e.g., B = 8,192 iterations) and the salt. Then MD5 is applied repeatedly: first to salt + password, then the result is hashed again together with the password — 8,192 times in total. The binary result is then converted to a readable string using a custom base64 encoding. The final hash is always 34 characters long.
Yes. All calculations run entirely in your browser using JavaScript. No passwords or hashes are sent to a server. You can verify this at any time by checking the Network tab in your browser's developer tools.
WordPress stores passwords in the wp_users table, column user_pass, in phpass format — a portable PHP password-hashing library written by Solar Designer in 2004 and the WordPress default since 2.5 (2008). A typical hash looks like: $P$BvAY9z5z.bC0FzG3p4rXmQE9YkE7gI/ — 34 chars, starting with $P$ as the phpass marker, followed by the iteration factor (B = 2^13 = 8192 rounds) and an 8-byte salt in phpass's base64 alphabet.
Internally, phpass is an iterated MD5 construction: salt + password is hashed once with MD5, then the binary hash (16 bytes) is concatenated with the password and MD5'd again — 8192 times in a row. The final 22 base64 characters of the last hash are the output. The fact that MD5 is broken as a cryptographic hash function (collision attacks since 2004) does not matter here: password hashing requires preimage resistance, not collision resistance — and preimages on MD5 remain open.
Since WordPress 6.8 (April 2025) the algorithm was extended: WordPress now uses bcrypt (PHP password_hash() with PASSWORD_BCRYPT) for new passwords — recognizable by the $wp$2y$ prefix. Phpass hashes ($P$) are still accepted and transparently migrated to bcrypt on next login. This tool produces $P$ by default for backward compatibility (every WP version 2.5 through 6.x reads it); on 6.8+ they auto-upgrade to $wp$2y$ on first login.
If you have lost admin login and email reset is not available (e.g. broken SMTP), you can write the generated hash directly to the database. Via phpMyAdmin or the MySQL CLI:
-- 1. Generate hash above, e.g.:
-- $P$BvAY9z5z.bC0FzG3p4rXmQE9YkE7gI/
-- 2. Run in the database:
UPDATE wp_users
SET user_pass = '$P$BvAY9z5z.bC0FzG3p4rXmQE9YkE7gI/'
WHERE user_login = 'admin';
-- 3. Verify:
SELECT user_login, user_pass FROM wp_users WHERE user_login = 'admin';
-- IMPORTANT: the table prefix may differ from the default 'wp_'
-- (see wp-config.php, variable $table_prefix).You almost always need this tool in one of five situations:
wp_users.user_pass via phpMyAdmin, log in. Time: 2 minutes.test1234).wp_insert_user().wp_users table from a backup or leaked dump. Drop the hash into verify, try a suspect password (password123, the WP default admin name admin, etc.) and immediately see whether weak credentials were in use.phpass with 8192 MD5 iterations is below the current recommended minimum (OWASP Password Storage Cheat Sheet, NIST SP 800-63B-Rev4 May 2025). Bcrypt with cost=12 or Argon2id with 19 MiB memory and 2 iterations are the current defaults. On an RTX 4090 Hashcat reaches about 80 MH/s against phpass — meaning an 8-char alphanumeric password falls in under an hour. Consequence: the hash is only half the story. If you still run WP sites below 6.8 in 2026, you should (1) plan an upgrade to 6.8+, (2) set admin passwords to at least 16 chars or a 6-word passphrase, (3) install WPS-Hide-Login + Limit-Login-Attempts + a 2FA plugin. This tool is an emergency device, not a security panacea.
$P$ hash still work in WordPress 6.8 and later?$wp$2y$) but still accepts all legacy formats on login ($P$, $H$, even pre-2008 unsalted MD5). On first successful login the hash transparently upgrades to $wp$2y$. So even in 6.8+ you can drop a $P$ hash into wp_users.user_pass — the admin logs in, the hash auto-migrates.wp_users table?wp-config.php (variables DB_NAME, $table_prefix). Access via phpMyAdmin (provided by your host like All-Inkl, Strato, Hetzner), Adminer, MySQL Workbench or the CLI mysql -u root -p dbname. Caution: in multi-site or renamed installs the wp_ prefix may be wpsite_, blog123_ or a random value.crypto.getRandomValues() on every generation. Hashes for password123 look different on every call. Verify does not care: the salt is encoded inside the hash, verify extracts it and compares in constant time.$P$ and $H$?$P$ is the WordPress portable marker, $H$ the phpBB3 marker for the same scheme. You may see $H$ in old forum databases or in plugins attempting cross-compatibility. WordPress reads both but always writes $P$ (in 6.8+, $wp$2y$).