Reset an authorized WordPress password safely.

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.

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

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.

The Function column, and the one dropdown that ruins this

phpMyAdmin's row editor puts a Function dropdown beside every field. It applies a MySQL function to whatever you typed before storing it, and on user_pass that is either exactly what you want or a silent way to lock yourself out — because the row still saves successfully either way.

Choosing MD5 while pasting a $wp$2y$ hash hashes the hash: a 32-character value that verifies against nothing. Leaving the function empty while typing a plain password stores the password in clear text, which fails to verify and leaves the real password sitting in the database. If you are unsure which of the two you just did, paste the saved value into the hash checker — it names the format in one look.

Prefer the SQL tab? The exact statements

The row editor and the SQL tab do the same thing. A statement is easier to review before you run it, and easier to get catastrophically wrong, so it comes with one rule: write the WHERE clause first, and prove it with a SELECT before you turn it into an UPDATE.

-- Run this FIRST. Whatever it returns is exactly what the
-- UPDATE below will change. One row means you are safe to continue.
SELECT ID, user_login, user_email, LEFT(user_pass, 7) AS hash_prefix
FROM wp_users
WHERE user_login = 'admin';

Swap wp_users for this site's actual table if the prefix is not wp_, and match on user_email instead if two accounts share a similar login. If that query returns nothing, you are in the wrong database — stop and read finding the WordPress users table rather than loosening the condition until something comes back.

-- Paste a hash you generated; keep the WHERE clause and the LIMIT.
UPDATE wp_users
SET user_pass = '$wp$2y$10$PASTE_YOUR_GENERATED_HASH_HERE'
WHERE user_login = 'admin'
LIMIT 1;

-- Emergency fallback only, when you cannot generate a proper hash.
-- Sign in immediately, then change the password inside WordPress.
UPDATE wp_users
SET user_pass = MD5('a-temporary-password')
WHERE user_login = 'admin'
LIMIT 1;

phpMyAdmin reports 1 row affected on success. 0 rows affected means the WHERE clause matched nothing — or matched a row that already held that exact value — so check the login before running it again.

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.