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.

7 min readUpdated 26 July 2026For authorized administrators

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.

1

Email reset

Use “Lost your password?” at the login screen when the account can receive email. This is the preferred path.

2

WP-CLI

With authorized shell access, run wp user update <user> --user_pass='new-password'. WordPress writes the right format.

3

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.

Database tables (default wp_ prefix shown)
  • wp_posts
  • wp_options
  • wp_users
  • wp_usermeta
  • wp_terms
  • wp_comments

A custom prefix shifts every name the same way. If _users isn't visible in the list, see finding the WordPress users table before continuing.

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

  1. 01
    Open the correct database.

    From the hosting control panel, open phpMyAdmin and select the database used by the WordPress site.

  2. 02
    Find the users table.

    Locate the table ending in _users, then browse it and find the authorized account by login or email. Unsure which table that is? See finding the WordPress users table.

  3. 03
    Edit only user_pass.

    Open the account row and replace the existing value in the user_pass field. Leave the username, email, role-related metadata, and other fields unchanged.

  4. 04
    Choose 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 — see the hash formats guide if you're unsure which one a target site expects.

  5. 05
    Save, sign in, then rotate again.

    Before saving, you can check the hash format locally to catch a typo. Test the new password immediately. Once access is restored, set a fresh password through WordPress so the site follows its normal password workflow.

wp_users — the row you're editing
ID1
user_loginadmin
user_pass$wp$2y$10$…
user_emailadmin@example.com
user_registered2024-03-11 09:12:04

Every other field in this row stays exactly as it was — user_pass is the only value this recovery touches.

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

  1. Change the password again in the WordPress dashboard and store it in a password manager.
  2. Confirm the account has the intended role; do not create a permanent emergency administrator.
  3. Remove temporary recovery code, exports, and any copies of the password or hash.
  4. Review email delivery, backup access, and two-factor authentication so the next recovery does not require database access.

Quick answers

Which hash format should I paste on WordPress 6.8 or later?

A $wp$2y$ bcrypt hash — the same format WordPress Core creates itself. Pasting a plain $2y$ bcrypt or MD5 value will not verify, because Core expects its own SHA-384 pre-hash step first. Generate the correct value locally rather than guessing.

Do I need to log the user out first?

No. Editing user_pass directly does not by itself end existing sessions — WordPress checks the password only at login, not on every request. If you specifically want to force a logout, rotate the site's salts instead; that invalidates every session immediately.

Is it safe to use MD5 as the recovery hash?

Only as a one-time emergency fallback, immediately followed by a real password change after signing in. WordPress still verifies MD5 for backward compatibility, but it is far weaker than bcrypt and should never be left in place.

What if I can't find a table ending in _users?

Check wp-config.php for $table_prefix — a custom or migrated install may use something other than wp_, and multisite networks name subsite tables with a numeric suffix. See the users-table guide for the full naming rules.

Primary reference: WordPress Learn: what to do when you forget your password.