What does the tool do?
If you forgot an administrator password and the email reset does not work, the last resort is replacing the user_pass value in the database. This tool produces that value: it picks a password or takes yours, hashes it with WordPress's own algorithm and prepares the UPDATE query. The details were checked against the WordPress 6.8 source on 22 October 2026.
Random passwords alone are covered by the password generator; here the output can be pasted into a database. It creates exactly one password.
Password, hash and wp-config salts
Three terms are often mixed up. The password is the text you type into the login form. The hash is the one-way value stored in the database; at login WordPress hashes what you typed the same way and compares. The keys and salts in wp-config.php sign session cookies and have nothing to do with user passwords.
The same password gives a different hash every time, because a random salt is mixed into each one. That is normal. To refresh the cookie keys, use the WordPress salt generator.
Which hash format should I pick?
| Format | Starts with | Length | Use for |
|---|---|---|---|
| Modern (default) | $wp$2y$ | 63 characters | WordPress 6.8 and later |
| Legacy portable (phpass) | $P$B | 34 characters | Default core 2.5 and later, including 6.7 and older |
If you do not know the site's version, choose the legacy portable format: WordPress 6.8 and later also verify it and upgrade it to the modern format on the first successful login. A 6.7 or older install does not understand the modern hash and rejects the login. It never contacts any site.
A custom authentication plugin can replace the core password functions. On such a site nobody can promise the hash will be accepted; check the plugin's documentation.
phpMyAdmin step by step
Try the normal reset or WP-CLI first. With WP-CLI, wp user update 123 --prompt=user_pass hashes the password on the site itself; 123 is just an example user ID. The SQL route is for when neither works.
- Back up the database.
- In phpMyAdmin select the correct database and check the real prefix of the
wp_userstable. - Adjust the username and table prefix fields for your site; both are examples and nothing is read from the site.
- Generate the hash for a generated or your own password, copy the SQL and run it on the SQL tab.
- If you paste the hash by hand, do not choose any function (MD5 included) for the
user_passfield; the value must be saved as it is. - Log in with the effective plaintext password shown below, not with the hash.
This tool runs the SQL nowhere and it bypasses WordPress's normal reset hooks. It cannot confirm success; you will only see the result by logging in.
The WordPress 6.8 change and cost
WordPress 6.8 stores passwords with bcrypt. The password is first hashed with HMAC-SHA384 and turned into Base64, then passed to bcrypt, and $wp is put in front; this way the end of a password longer than 72 bytes still counts. Core does not choose the bcrypt cost itself, it inherits PHP's default: 10 before PHP 8.4, 12 from 8.4.
So the tool asks for the cost explicitly and defaults to 12; you can pick 10 or 12. Both verify on 6.8 and the site may rehash later. A higher cost slows attackers down and takes a moment here; the page keeps responding.
Old MD5 hashes may still be accepted by WordPress and are upgraded at login. That is an old fallback, though, and this tool produces no MD5 output.
Privacy and limits
Your password and its hash are computed in your browser and never sent to a server. The share link contains neither your password, your hash nor your username.
This is not protection against a compromised device or browser extensions, and it does not promise that values are erased from memory. Leading and trailing spaces are trimmed the way WordPress trims them when it generates a hash; the tool warns you and shows the effective password you must type. Application passwords, reset keys and post passwords are out of scope.
Frequently asked questions
Should I pick modern or legacy?
Pick modern if the site runs WordPress 6.8 or later. If unsure, legacy portable works on default core 2.5 and later; on 6.8 and later it is upgraded at the first successful login.
Why does the same password give a different hash each time?
A random salt is mixed into every hash. All the different-looking hashes verify the same password; that is expected behavior.
Is my password sent to a server?
No. The password and hash are calculated in your browser, sent in no request and never written to the share link. Your device still has to be trustworthy.
Do I need MD5 in the SQL?
No. Do not pick the MD5 function that older tutorials mention; the hash is already computed and must be stored as it is. Choosing a function corrupts it.
Is this the same as the wp-config salts?
No. Salts and keys sign session cookies and do not store a user password. Use the related salt tool for those.
Why was I logged out after WordPress 6.8?
According to the official announcement the update normally keeps existing passwords and logged-in sessions; hashes are upgraded at the next login. Unexpected logouts need a separate investigation of the site. This tool cannot diagnose a site.