Can’t Log In to WordPress on localhost: Login Loops and Cookie Errors

This article is a localized edition of the Japanese original. Read the Japanese original

When you cannot log in to WordPress on localhost, the cause is usually that the URL you open in the browser does not match the site URL stored in WordPress, or that the login cookie is not being saved. This article narrows down the cause from what you see on screen and fixes it with wp-config.php and WP-CLI. Everything was checked with WordPress 6.9 and WP-CLI 2.12 as of November 2026.

Start with the symptom

1. Match the site URL to the URL you open

WordPress uses siteurl (WordPress Address) and home (Site Address) in the database to decide where to send you after login and how to handle cookies. If you open http://localhost:8080 in the browser but the stored URL is http://localhost (no port) or http://127.0.0.1:8080, you are sent to a different address after logging in and end up logged out again.

You can check the stored values with WP-CLI.

wp option get siteurl
wp option get home

If they differ, update them to the URL you open in the browser. Do not add a trailing /.

wp option update siteurl 'http://localhost:8080'
wp option update home    'http://localhost:8080'

If you cannot use WP-CLI, add these two lines to wp-config.php; they take priority over the database values (put them above the "That's all, stop editing!" line).

<?php
define( 'WP_HOME',    'http://localhost:8080' );
define( 'WP_SITEURL', 'http://localhost:8080' );

For cookies, localhost and 127.0.0.1 are different sites. Pick one and make your browser bookmarks match it.

2. When you get a cookie error

When the login screen opens, WordPress saves a test cookie (wordpress_test_cookie) and checks that it comes back when you submit the login form. If it doesn't, you get an error saying cookies are blocked.

Things to check:

• Is COOKIE_DOMAIN set in wp-config.php? If a copied production config still has something like define( 'COOKIE_DOMAIN', 'example.com' );, the browser will not accept that cookie on localhost. Delete this line locally (without it, the cookie is valid only for the host name you opened).
• Also delete COOKIEPATH, SITECOOKIEPATH and ADMIN_COOKIE_PATH if production values are left over.
• Do the URLs in section 1 match?
• Are your browser settings or an extension blocking cookies for localhost? If old cookies are left over, clear the site data for localhost and try again.

You do not need to set COOKIE_DOMAIN to localhost locally.

3. When you see “Cookies are blocked due to unexpected output”

Cookies must be sent before the page body. If a PHP warning or whitespace is output first, the cookie cannot be sent and you get this error.

Common causes:

• WP_DEBUG_DISPLAY is on in wp-config.php, and warnings (Warning, Deprecated) from a plugin or theme are printed on screen
• wp-config.php or functions.php starts with a BOM from being saved in the wrong encoding, or has spaces or blank lines before <?php
• There is a blank line after the closing ?> at the end of a file

First, send warnings to a log instead of the screen.

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );       // Log to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // Don't show on screen
@ini_set( 'display_errors', 0 );

If you can log in after this, look at wp-content/debug.log to find the plugin or theme producing the warnings. When saving files in your editor, choose "UTF-8 (without BOM)".

4. After copying the production database

Right after importing the production database, siteurl and home still hold the production URL, so the login screen and the post-login redirect go to production. Replace the URLs in bulk with WP-CLI.

# Check how many replacements will be made first
wp search-replace 'https://example.com' 'http://localhost:8080' --skip-columns=guid --dry-run

# If that looks right, run it
wp search-replace 'https://example.com' 'http://localhost:8080' --skip-columns=guid

# Clear the object cache if you use one
wp cache flush

wp search-replace also fixes the string lengths in serialized data. Replacing with SQL REPLACE can break settings.

If production uses a security plugin that changes the login URL, two-factor authentication, or a plugin that limits logins by IP address, those settings are active locally too. Deactivate the plugin temporarily to check.

wp plugin list --status=active
wp plugin deactivate plugin-name

If you cannot use WP-CLI, rename that plugin's folder inside wp-content/plugins/ and WordPress will stop loading it.

5. When you are sent to https and the page won’t open

If you run the site over http:// locally but production settings are left over, you get sent to https://localhost and the page will not open.

• If wp-config.php has define( 'FORCE_SSL_ADMIN', true );, delete it locally or set it to false.
• If siteurl and home are still https://, change them to http:// using section 1 or 4.
• Also check that .htaccess does not still contain a production rewrite that sends http to https.

The opposite case: if you open the site over https:// through a reverse proxy, for example with Docker, WordPress may not realize it is being served over HTTPS and bounce you back and forth with the login screen. If the proxy sends the X-Forwarded-Proto header, add this near the top of wp-config.php.

<?php
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

The wp-config.php generated by the official WordPress Docker image already includes the same code.

6. When you don’t know the password

Local environments often cannot send email, so resetting through "Lost your password?" does not work. Change the password directly with WP-CLI.

# Check the usernames
wp user list --fields=ID,user_login,roles

# Change the password (no notification email)
wp user update admin --user_pass='new-password' --skip-email

If you cannot use WP-CLI, you can also edit the wp_users table with a tool such as phpMyAdmin.

Site URLs by local environment

The form of the site URL depends on the tool. Set siteurl and home to exactly the URL shown in your browser's address bar.

• Docker (official image): the URL including the published port, such as http://localhost:8080 when you run docker run -p 8080:80
• MAMP: Apache's default port is 8888, so http://localhost:8888
• Local and Laragon: each site gets its own host name (such as sitename.local or sitename.test)

Related articles

• Fixing cookie errors on the WordPress login screen
• WordPress Address vs. Site Address
• Replacing URLs with WP-CLI search-replace
• Resetting a WordPress password with phpMyAdmin

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)