Forgot your WordPress password? Recover your account without a plugin

Identify the account you are trying to recover

You reach the login form and none of your passwords seems to work. Before requesting a new one, check that you are on the correct site. Your hosting account, domain registrar account, and WordPress user are generally three separate accounts. Resetting the first does not automatically change the other two.

For a self-hosted WordPress installation, login is usually at your site’s address followed by /wp-login.php. Opening /wp-admin/ may also take you there. A subdirectory installation or custom login system may use another address. Use a trusted bookmark or your host’s instructions rather than a link sent by a stranger.

If you sign in with a WordPress.com account, use its recovery process. An account created on WordPress.org to participate in the forums does not, by itself, grant access to your site’s administration. When login uses an external identity provider, that external account may be the one you need to recover.

This guide is for the account owner or a person explicitly authorized to administer it. It explains how to establish new access. WordPress stores a password hash, not a readable copy that can simply be displayed in a table.

Choose the route that matches your available access

Start with approach 1 if you can receive messages sent to the email address in your profile. It uses the native recovery link and requires no server changes. It is the most direct route when the site’s email works.

Approach 2 is suitable if a session remains open on one of your devices or an authorized administrator can help. It lets you correct the profile through the dashboard. Keep that session available during diagnosis: signing out everywhere before confirming new access can remove your only way in.

Approach 3 uses hosting access when the first two routes are unavailable. It requires already authorized server access or ownership verification by the provider. WP-CLI offers a route suited to intermediate users; phpMyAdmin remains a more delicate alternative that must target the exact account.

Do not change the user’s role to resolve a forgotten password. An author can recover their account without becoming an administrator. Do not restore the entire database for this problem alone either: that could undo content, registrations, or orders unrelated to login.

Approach 1: request a password reset link

Open the login page from a known address and check the domain and HTTPS connection. Click “Lost your password?”; the wording may vary with the language or login theme. Enter the account username or the email address stored in its profile, then send one request.

Wait for the message in the relevant mailbox and check spam. Open the most recent message corresponding to your request. In the usual process, it contains a link allowing you to choose a new password. You should not need to pay a service or provide hosting credentials to do this.

Before following the link, check its destination. It must match your installation or the identity service actually in use. The link contains a temporary secret: do not publish it in a forum or leave it visible in a shared screenshot. Someone working on the site does not need to receive it if you can complete the process yourself.

Choose a unique password, ideally generated and saved in your password manager. Confirm the change, then return to the normal form to sign in. If your browser still fills in the old value, replace it and update the saved entry. A successful reset and a successful login are two separate checks.

If the link is invalid or has expired

A recovery link is not permanent access. It contains a key tied to the account and request. A newer request may make a previous key unusable; a used or overly old key must no longer be used to set a password. Do not try to manually fix that key in the address.

Return to the forgotten-password form and make a new request. Record the request time and use the link from that request. If your mailbox groups messages into a conversation, open the corresponding message. The email that arrives most recently may belong to an older request.

If the link appears truncated, use the complete address provided in the message, without adding spaces or removing parameters. Test in an up-to-date browser on the expected domain. A redirect to the old domain after a migration is a configuration clue; requesting twenty new links will not resolve that inconsistency.

If every new link fails immediately, record the request time, starting domain, final destination, and error text. Send those details to the site maintainer without disclosing the key. They can investigate link handling, redirects, and login components using a timestamped test.

Distinguish a replaced link from a damaged link

If the message did arrive, note when you triggered the request and check that the link opens the expected domain. Arrival order may differ from request order if delivery delayed a message. If you already requested several links, choose the email from the last request you triggered. Make only one new request after confirming the installation and use that request’s complete link. Requesting another link between comparisons invalidates the test.

If you compare the copied address with the link in the message, inspect them locally in a text editor. Check that the path and the action, login, and key parameters are present in a native link, without added spaces or truncation. On a site that customizes the form, the path and parameters may differ. In that case, compare the address actually issued by that site. Treat the key as a secret. Avoid pasting the link into a search engine, public checker, or support ticket.

In the browser, use a fresh private window and close it after the test. If you need to follow a redirect, enable Preserve log in Network before clicking. Record the domain and path of the first hop and whether the parameters remain present, masking their values. WordPress may remove key and login from the address after placing the key in a temporary cookie. That redirect is part of the native process. A hop that removes a parameter before the link reaches WordPress is a different case.

Interpret test results without sending email

An example comparison to reproduce on a copy with a fictitious account: open the link from a first request, then create a second request for the same account. Core stores a new key hash for that user; the first key then no longer matches the expected one. A link with a truncated key may also be rejected. The on-screen text therefore does not distinguish a replaced key from a damaged key. This scenario explains the mechanism; it is not a report of testing your installation.

To distinguish link alteration from expiration, privately compare the issued path and parameters with those that actually reach WordPress. Perform this check on a fictitious account on the copy, without reusing a customer link in a public tool. Core provides a default lifetime of one day, which can be changed through the password_reset_expiration filter. Do not reduce this lifetime in production to reproduce an error. Link validation and submission of the new password are separate stages: verify form opening and final login separately.

Locate a redirect before correcting delivery or login

If every new key fails immediately, ask the maintainer to compare, on a copy, the link issued before delivery with the first request that reaches WordPress login. Click tracking, an email gateway, or a redirect rule may alter the address. First check whether the domain, path, or parameter names changed, then privately compare values using a fictitious account. A redirect that removes parameters after establishing the reset cookie is normal. If parameters disappear before that stage, or the cookie is not sent back after a domain or path change, the form may fail.

For a real account, retain only the time, expected domain, first hop, and displayed message. Do not open a page on an unexpected domain or enter credentials there. The maintainer can correct a targeted rule on the copy and test one new request. The expected result is the new-password form on the intended domain, followed by a successful login if you finish the reset yourself. If the test changes another login screen’s behavior, restore the previous rule. If you are only diagnosing the link’s route, stop at the form; do not submit a real password.

If no recovery message arrives

First check the mailbox associated with the user profile, which may differ from the site’s general contact address. A site may send administrative notifications to one address while associating your personal account with another. If you know your username, try it in the form to avoid mistyping the email address.

Search for the site name in spam and automatically sorted folders. Also check that the mailbox is not full and can receive an ordinary message. These observations distinguish a general reception problem from one specific to messages sent by WordPress.

A page saying that the request was processed does not prove that the email reached your mailbox. Delivery may be blocked by hosting, email configuration, or a filter. If you no longer have dashboard access, immediately installing a sending plugin is not an available solution: use an authorized administrator or support instead.

Avoid making repeated requests a few seconds apart. You mainly risk receiving a series of hard-to-distinguish messages. Record one precise test and ask support whether its message was sent, rejected, or deferred. Account recovery can proceed through another approach while deliverability is diagnosed separately.

Approach 2: use an open session or an authorized administrator

If your session still works on a trusted device, open your profile from the dashboard. Check the username and email address before making any change. In account management, use the action to set or generate a new password, then save the profile. Wait for confirmation that it was saved.

Then test the new access in another window. Do not rely on your old session remaining open: it does not demonstrate that you correctly saved and retained the new value. Update your password manager once the independent login works.

If another administrator intervenes, they must first verify your identity through an already known channel. They open the user list, select your exact account, and use the password-management functions permitted by their role. Depending on configuration, they may send a reset link or set a new value. Sending a link still depends on your email working.

Agree on a secure transmission method if a temporary value must be given to you, then replace it from your profile after signing in. Do not use a public comment or a document shared with the entire team. On a multisite network, some actions are reserved for the network administrator: a missing expected button may reflect account permissions rather than a site failure.

Approach 3: prepare recovery through hosting

Sign in to the hosting account through its usual address. If that account is also inaccessible, recover it through the provider before attempting to modify WordPress. Support may request the ownership evidence required by its process. Knowing the domain name or a public username is not enough to prove authorization to take control of the account.

Locate the relevant installation, its path, and its associated database. One hosting account may contain production, staging, and an old copy. A reset on the wrong installation may display success without changing your usual login. Prepare a restorable backup before intervening directly in the database.

Some hosts provide a WordPress user-management function or administrative login from their panel. Use it if it is intended for your site and your account is authorized. Once inside WordPress, follow the profile-editing procedure described earlier.

Otherwise, WP-CLI allows a targeted intervention over SSH. The tool must be available and you must know how to open an authorized session. Do not install a random recovery script in the public folder: it could become another entry point if access is poorly protected or the script remains in place.

With WP-CLI, identify the account before changing it

Open an SSH session and change to the correct installation’s directory. Verify the path against your host’s information. The first command below reads the configured home address; the second displays the selected user’s information. Replace IDENTIFIANT with your actual username rather than assuming it is admin or has ID 1.

Read the result before continuing. If the domain, email address, or account does not match what you know, stop the modification and clarify which installation is being targeted. A difference may come from an old copy, a legitimate change, or account tampering. It should not be corrected at random merely to make the next command work.

The displayed user information may be private. Keep it in your session and redact it before taking a screenshot for a forum. On a multisite network, clarify the relevant site and network account: changing a password shared across the network may affect more than one subsite.

wp option get home
wp user get IDENTIFIANT

Set the new password through a separate prompt

The following command asks for the user_pass field’s value when it runs. Replace only the username in the command. Prepare a unique password in your manager, then enter it when WP-CLI prompts you. This avoids putting the secret directly in a command line retained by shell history.

Interactive entry does not remove the need to protect your session: a recorded terminal, screen share, or screenshot can still expose information. Perform the operation in a trusted session. Do not choose an option that deliberately prints the new password in output unless you need it.

After the update confirmation, try a normal browser login. The command changes the targeted account’s password; it does not remove a two-factor authentication requirement or automatically correct redirect rules. If login still fails, record the exact message before resetting again.

Do not change the role, username, and email address at the same time. Changing one value at a time shows what actually resolved the problem. If WP-CLI fails before executing the action, send the technical error to the hosting administrator rather than adding random options.

wp user update IDENTIFIANT --prompt=user_pass

An alternative with phpMyAdmin when WP-CLI is unavailable

This alternative requires authorized phpMyAdmin access and a prior backup. Select the database actually used by the installation. The configuration file identifies its name and table prefix; consult those details without sharing the whole file. The prefix is not necessarily wp_.

Open the users table, usually named with that prefix followed by users. Locate the row using the account’s username and email address. Check its ID before selecting Edit. In the user_pass field, select phpMyAdmin’s MD5 function and enter the new password as the value, then save only that row.

This procedure uses recovery compatibility: after a successful login, WordPress replaces the temporary hash with its current hashing mechanism. MD5 is not a choice to adopt when designing your own password system. Do not simply paste a plaintext password into the field without the intended transformation, and do not send the secret to an online hash generator.

Sign in immediately, then use your WordPress profile to establish your final access. If you cannot unambiguously identify the correct database or row, have the provider carry out the operation. Do not execute a change targeting the entire table or alter permissions to compensate for a misidentified account.

If the password works but another screen blocks you

A request for a one-time code generally means you have reached a second authentication step. Resetting the password again does not recreate your authenticator app. Use the recovery codes you saved or the process provided by the supplier of that protection. Do not share those codes with someone you met on a forum.

For WordPress.com, recovering a phone, email address, or account follows separate processes. If you have no remaining verification method, use its official account recovery form. On a self-hosted installation, contact the administrator or provider managing two-factor authentication, with appropriate ownership evidence.

If the form reloads without opening the dashboard, first check the site’s cookies and final address. An HTTP/HTTPS, domain, or cache inconsistency can interrupt the session even when credentials are correct. Test in a private window or another trusted browser without globally disabling your protections.

Finally, a signed-in account that cannot install a plugin has not necessarily been recovered incorrectly. Its permissions may be those of an author, editor, or subsite administrator. Compare the expected actions with the authorized role before requesting a permissions change.

Confirm recovery and reduce the risk of another forgotten password

Recovery is verified when you can sign in with the new credentials in an independent session, open your profile, and perform an authorized action. Check the account email address. If you change it, follow any confirmation steps: a field visibly changing does not always mean that the new address is already verified.

Save the exact domain, username, and password in your password manager. Keep the site, hosting, and WordPress.com entries distinct to avoid further confusion. Each person managing the site should have their own account with the necessary permissions rather than a shared username whose latest password change nobody knows.

If the forgotten password was simply accidental, check your devices and close unneeded sessions through the available profile functions. If you discover an unfamiliar address, an unrequested change, or an additional administrator, also address possible compromise. Recovering a password does not establish that the site and email account are secure.

Finally, prepare for future recovery: an accessible mailbox, documented hosting-account access, and backup codes kept somewhere safe. A specialist plugin can supplement authentication on a self-hosted site, but it is not required for the methods described here. Add a tool only after you have stable access again and understand its own recovery mechanism.