Locked Out of WordPress Admin? How to Get Back In

There are five ways back into a WordPress site you cannot log into, and they carry very different risks. Work them in this order: the password reset email, cookies and browser, the database, WP-CLI, and only then a temporary file on the server.

The reason for that order is not difficulty. It is that the last two routes create a window in which anyone who finds the file can take the site — and WordPress says so itself, in both cases.

One thing to establish before you start, because it determines whether this takes two minutes or two hours: can your site send email at all? The reset link is the cheapest route by a wide margin, and it is the route that fails silently on a large proportion of WordPress sites.

---

First, work out which lockout you have

They look similar and they are not.

What happens	What it usually is
Password rejected, no error about cookies	Wrong password, or the wrong username — both fields are case-sensitive
"Cookies are blocked or not supported"	Browser cookies, or a site URL change that invalidated them
Login succeeds, then bounces straight back to the login page	A redirect loop — usually a site URL mismatch or a plugin
"You do not have sufficient permissions to access this page"	You are logged in, but your role or capabilities are broken
Reset email never arrives	The site cannot send mail — not a login problem at all
Blocked after several attempts	A security plugin or firewall has locked your IP
A blank page or a critical error at /wp-admin	Not a lockout. It is a fault — see when WordPress breaks

The last row saves the most time. If the login screen never renders, you do not have a credentials problem, and nothing on this page will help until the underlying error is fixed.

---

Before you touch the database

Back up first. Files and database, both. Two of the routes below involve editing user records directly, and a mistyped WHERE clause is not recoverable from memory.

Note the exact username you are trying. WordPress's own troubleshooting guidance points out that the username and password fields are case-sensitive, and a surprising share of lockouts are that and nothing more.

---

The routes back in, by risk

Step 1 — Use "Lost your password?"

The link under the login form. Enter the username or the email address on file, and WordPress emails you a reset link.

If it arrives, you are done. Nothing further on this page applies.

If it does not, do not assume it is broken WordPress. Check spam first, then treat it as what it almost certainly is — a site that cannot send email. That is a separate problem with a separate fix, and it is worth reading WordPress email: why your site's emails never arrive once you are back in, because the same failure is silently affecting your password resets, order confirmations and contact forms.

And the same failure is why you did not get a recovery-mode email if the lockout came from a fatal error. WordPress's entire self-rescue mechanism is delivered by email.

Step 2 — Rule out cookies and the browser

WordPress authenticates with cookies, and it says so plainly: "WordPress uses cookies for authentication. That means that in order to log in to your WordPress site, you must have cookies enabled in your browser."

So:

• Clear your cookies for the site and clear the cache. WordPress's own advice after a site move is to "always try to delete your cookies and if you are using a caching plugin, the server cache"
• Try a private window, and then a different browser entirely
• Check the error text. "Cookies are blocked or not supported by your browser" is WordPress's test cookie failing, not your password being wrong

Thirty seconds, and it resolves more lockouts than the dramatic routes below.

Step 3 — Check for a redirect loop or a site URL mismatch

If the login appears to succeed and then returns you to the login form, the cookie is being set for a domain the site is not actually being served from.

This is the classic symptom after moving hosts, adding SSL, or switching between www and non-www. The site URL stored in the database no longer matches the address in your browser, so the authentication cookie is written for one host and read from another.

The override goes in wp-config.php:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Match the scheme and host exactly — including whether there is a www. These two constants take precedence over what is in the database, which is why they work when the admin is unreachable.

Take them back out once you have fixed the stored values, or the site becomes hard to move next time.

Step 4 — Reset the password in the database

This is where the risk starts, and it is also the most reliable route.

Through phpMyAdmin or your host's database tool: open the wp_users table (your prefix may differ), find your user row, and set user_pass to a new value using the MD5 function from the dropdown.

A note that most guides have not caught up with. WordPress 6.8 moved password hashing to bcrypt, and this method still works anyway, because "The wp_check_password() function retains support for passwords that were hashed using phpass, which means existing password hashes won't be invalidated." An MD5 value set directly in the database is accepted at login and automatically rehashed with bcrypt the first time you use it. You do not need to do anything about it.

Two things to check while you are in there, because they cause the "you do not have sufficient permissions" variant rather than a rejected password:

• The table prefix. $table_prefix in wp-config.php must match the tables actually present. A mismatch after a migration produces a working login that has no permissions
• The wp_capabilities row in wp_usermeta for your user. If a role was stripped, the password is fine and the account is powerless

If you have shell access, WP-CLI is the same fix without the risk of a hand-edited query:

wp user update 1 --user_pass='your-new-password'

Prefer this whenever it is available. It validates the user, writes the hash correctly, and leaves nothing behind.

Step 5 — Set the password from a theme file, then remove it

Only if the database is out of reach and you have FTP.

Add one line to your active theme's functions.php, immediately after the opening <?php:

wp_set_password( 'my_new_password', 1 );

The 1 is the user ID.

WordPress's warning is the part that gets left off: "Once you are able to login, make sure to go back and remove that code. It will reset your password on every page load until you do so."

Read that again. While that line is present, every single page view resets your password to that value — which means the password is effectively published in a file on your server and cannot be changed. Log in, remove the line, save, then change the password normally from the admin.

Step 6 — The emergency password reset script, as a last resort

WordPress publishes a standalone script for exactly this situation, and it comes with the bluntest caution in the documentation:

"Delete emergency.php from your server when you are done. Do not leave it on your server, as someone else could use it to change your password."

The stated conditions are also specific: you must know the administrator's username, the file goes in the root of the WordPress install, not in the plugins directory, and "For security reasons, remember to delete the script when you are done."

Treat this as the route of last resort, not the first thing to try. While that file is on your server, the site's admin password can be changed by anyone who finds it.

---

The two lockouts that are not password problems

A security plugin or firewall blocked your IP

Login-limiting is doing its job, and the site is behaving correctly.

The usual routes back: wait out the lockout window, connect from a different network, or — if you have file access — deactivate the plugin by renaming its folder in wp-content/plugins. The method, and how to do it without losing settings, is in find a WordPress plugin conflict safely.

If the block came with a notification email you never received, you have the email problem again.

The admin account is gone, or was never yours

If the user record has been deleted, or you inherited a site without credentials, none of the reset routes apply — there is nothing to reset.

Adding a user directly in the database is possible, but it involves writing rows into both wp_users and wp_usermeta with the correct serialised capabilities, and getting it wrong produces an account that logs in and can do nothing. WP-CLI does it in one command and is worth the effort of getting shell access:

wp user create newadmin you@example.com --role=administrator

And if an admin account you do not recognise is the reason you are locked out, stop treating this as a lockout. That is a compromise, and the sequence is in my WordPress site is hacked: a triage plan.

---

Once you are back in

Three things, in this order.

1. Change the password properly from Users → Profile, so nothing you set by hand is left in a file or a database field you edited
2. Remove anything temporary — the functions.php line, emergency.php, the WP_HOME overrides if you fixed the stored values
3. Test that the site can send email, by triggering a password reset for a test account

That third one is the only one that prevents a repeat. Every route above except the reset link involved FTP or a database, and the reason you needed them is that the cheap route was not working.

Why a WordPress site cannot send its own password resets is a deliverability question rather than a WordPress one — authentication, the sending domain, and the reputation of whatever is doing the sending. The Email Deliverability Playbook covers the setup end to end, including the records to publish and the platform-by-platform paths. Available here.

---

Frequently asked questions

How do I get back into WordPress admin if I forgot my password?
Start with the "Lost your password?" link under the login form. If the email does not arrive, reset the password directly in the database by setting the user_pass field with the MD5 function in phpMyAdmin, or with WP-CLI using wp user update. Both are documented WordPress methods.

Why is my WordPress password reset email not arriving?
Almost always because the site cannot send email. WordPress uses PHP mail() by default, which frequently fails authentication checks and is rejected or filed as spam. The same failure affects order confirmations, contact form notifications and fatal-error recovery emails.

Does resetting a WordPress password with MD5 still work?
Yes. WordPress 6.8 moved to bcrypt hashing but retained support for older hashes, so an MD5 value set directly in the database is still accepted at login and is automatically rehashed with bcrypt the first time it is used.

Why does WordPress keep redirecting me back to the login page?
Usually a site URL mismatch — the address in your browser does not match what is stored in the database, so the authentication cookie is set for one host and read from another. Defining WP_HOME and WP_SITEURL in wp-config.php overrides the stored values and breaks the loop.

What does "cookies are blocked or not supported by your browser" mean?
WordPress authenticates with cookies and sets a test cookie to check they work. That message means the test failed. Clear the site's cookies and your cache, try a private window, and clear any caching plugin's cache if the site was recently moved.

Is it safe to reset a password from functions.php?
Only briefly. WordPress warns that the code must be removed once you can log in, because it resets your password on every page load until you do — which means the password sits in a file on your server and cannot be changed while the line is there.

How do I create a new WordPress admin user without logging in?
WP-CLI does it in one command with wp user create. Doing it by hand in the database requires rows in both wp_users and wp_usermeta with correctly serialised capabilities, and an error there produces an account that logs in but has no permissions.

I can log in but get "you do not have sufficient permissions".
That is a role problem rather than a password problem. Check the wp_capabilities entry in wp_usermeta for your user, and check that the table prefix in wp-config.php matches the tables actually in the database — a mismatch after a migration produces exactly this.

---

What to do next

Try the reset link first, and notice what happens. Whether that email arrives tells you which half of this page you need.

If it does not arrive, use the database route to get back in — then fix the email, because it is the reason a two-minute problem became this one.

---

Related guides

• When WordPress breaks: a diagnostic order — if the login screen itself will not load
• Find a WordPress plugin conflict safely — when a plugin is doing the blocking
• Error establishing a database connection: fixed — if the database route is unavailable too
• WordPress email: why your site's emails never arrive — why the reset link never came
• How to set up SMTP in WordPress properly — the fix that prevents the repeat
• My WordPress site is hacked: a triage plan — if the lockout was not your doing
• WordPress login security without locking yourself out — hardening that does not backfire