Account recovery guide
Reset an authorized WordPress password safely.
Choose the least invasive recovery method first. Touch the database only when normal recovery and WP-CLI are unavailable.
Choose the safest available path
A lost password does not automatically require database access. The normal reset route preserves WordPress’s intended controls and leaves less room for a typo to affect the wrong account.
Email reset
Use “Lost your password?” at the login screen when the account can receive email. This is the preferred path.
WP-CLI
With authorized shell access, run wp user update <user> --user_pass='new-password'. WordPress writes the right format.
phpMyAdmin
Use this fallback only when email and shell recovery are unavailable but authorized database access exists.
Before opening phpMyAdmin
Record the site URL, database name, and a fresh backup location. Check wp-config.php if you need to identify the configured database or table prefix. The users table is often named wp_users, but installations commonly use a different prefix such as client_users or wpx9_users.
Decide which authorized account you are restoring before making the change. Confirm the account by user_login or email—never by a vague memory of its row position.
phpMyAdmin recovery, step by step
- 01Open the correct database.
From the hosting control panel, open phpMyAdmin and select the database used by the WordPress site.
- 02Find the users table.
Locate the table ending in
_users, then browse it and find the authorized account by login or email. - 03Edit only
user_pass.Open the account row and replace the existing value in the
user_passfield. Leave the username, email, role-related metadata, and other fields unchanged. - 04Choose a compatible recovery value.
For a current WordPress installation, generate a local
$wp$2y$hash. For a one-time emergency fallback, phpMyAdmin’s MD5 function remains compatible with WordPress legacy verification. Do not use an arbitrary online hash format. - 05Save, sign in, then rotate again.
Test the new password immediately. Once access is restored, set a fresh password through WordPress so the site follows its normal password workflow.
Why a manual hash can fail
The most common causes are selecting the wrong users table, editing a similarly named account, using a table prefix that does not belong to this site, or pasting a hash format that the installation does not expect. WordPress 6.8+ stores $wp$2y$ for new default bcrypt hashes, not plain $2y$.
Plugins can customize authentication, and WordPress multisite or external identity systems can add further constraints. If the account still cannot sign in after a confirmed change, stop making repeated database edits and investigate the site’s authentication plugins, role mapping, and error logs.
After access is restored
- Change the password again in the WordPress dashboard and store it in a password manager.
- Confirm the account has the intended role; do not create a permanent emergency administrator.
- Remove temporary recovery code, exports, and any copies of the password or hash.
- Review email delivery, backup access, and two-factor authentication so the next recovery does not require database access.
Primary reference: WordPress Learn: what to do when you forget your password.