Fix 'ERROR: Cookies are blocked or not supported by your browser' in WordPress Login

What's happening

You open yourdomain.com/wp-login.php, enter valid credentials, and instead of reaching the dashboard you get:

ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.

Nine times out of ten, your browser is fine. The message is misleading. The real culprit is a URL mismatch — WordPress thinks it lives at one address while your browser visits another. The login cookie gets set on the wrong domain and discarded immediately.

Root causes (ranked by frequency)

URL mismatch in the database — siteurl or home options in wp_options point to a different scheme or subdomain (e.g., stored as http:// but you're accessing via https://, or www. vs bare domain).
Wrong COOKIE_DOMAIN in wp-config.php — an old or incorrect constant overrides cookie scope.
Reverse proxy / CDN not forwarding the correct host header — WordPress sees a different hostname than the browser.
Third-party caching or security plugin stripping Set-Cookie headers.
Browser really does block cookies — rare, but the fastest to rule out.

Step 1 — Rule out the browser in 60 seconds

Open a private/incognito window (Ctrl+Shift+N in Chrome/Edge, Ctrl+Shift+P in Firefox). Log in from there. Success means the problem is browser-level: a rogue extension or strict cookie settings. Clear site data for your domain:

Chrome: DevTools → Application → Storage → Clear site data.
Firefox: DevTools → Storage → Cookies → right-click your domain → Delete All.

Incognito fails too? The problem is server-side. Move on to Step 2.

Step 2 — Check siteurl and home in the database

Run this in phpMyAdmin or via WP-CLI:

# WP-CLI (fastest)
wp option get siteurl
wp option get home

Both values must exactly match what's in your browser's address bar — same scheme (https vs http), same subdomain (www vs none). Even one character off breaks the cookie. Fix mismatches with:

wp option update siteurl 'https://yourdomain.com'
wp option update home    'https://yourdomain.com'

Can't reach wp-admin at all? Override the values temporarily in wp-config.php:

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

Save the file and try logging in again.

Step 3 — Remove or fix COOKIE_DOMAIN in wp-config.php

Search your wp-config.php for any of these constants:

grep -E 'COOKIE_DOMAIN|COOKIEPATH|SITECOOKIEPATH' /var/www/html/wp-config.php

Found a COOKIE_DOMAIN pointing to an old domain? Comment it out:

// define( 'COOKIE_DOMAIN', 'old-domain.com' );  // ← comment this out

WordPress derives the cookie domain automatically from siteurl. You only need COOKIE_DOMAIN on multisite installs sharing cookies across subdomains:

// For a single site — don't set COOKIE_DOMAIN at all.
// For multisite sharing cookies across *.yourdomain.com:
define( 'COOKIE_DOMAIN', '.yourdomain.com' );  // note the leading dot

Step 4 — Check for http/https mismatch behind a proxy

Here's a subtle one. Your server forces HTTPS, but WordPress's siteurl is still http://. A load balancer terminates SSL before PHP ever sees the request. PHP's $_SERVER['HTTPS'] comes up empty, so WordPress skips the Secure flag on the cookie — or sets it on the wrong domain entirely.

Add this to wp-config.php to fix it:

// Tell WordPress HTTPS is active even though PHP sees HTTP
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

On Nginx, make sure the upstream block actually passes that header:

proxy_set_header X-Forwarded-Proto $scheme;

Step 5 — Deactivate plugins via the file system

Still stuck? A security or caching plugin may be stripping the Set-Cookie header. Common culprits: Wordfence, WP Super Cache, W3 Total Cache, Cloudflare APO. Disable everything at once without needing wp-admin:

# Rename plugins folder to disable all at once
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Try logging in. Works? Rename the folder back, then reactivate plugins one at a time to find the offender:

mv /var/www/html/wp-content/plugins_disabled /var/www/html/wp-content/plugins

Once you find the bad plugin, look for settings like "Cache logged-in users" or "Remove cookies for anonymous users" and turn them off.

Step 6 — Verify the cookie is actually being set

Open DevTools (F12) → Network tab → submit the login form → click the wp-login.php POST request → check Response Headers. You should see something like:

Set-Cookie: wordpress_sec_... ; path=/wp-content/plugins; secure; HttpOnly
Set-Cookie: wordpress_logged_in_... ; path=/; secure; HttpOnly

Headers present with the correct domain and path? WordPress is doing its job — the problem is client-side (browser policy, an extension, or an iframe). No Set-Cookie at all? Your proxy or caching layer is stripping it.

For Nginx, add a dedicated block for the login page that bypasses caching entirely:

location = /wp-login.php {
    fastcgi_cache_bypass 1;
    fastcgi_no_cache     1;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Verification

Clear all browser cookies for your domain.
Navigate to https://yourdomain.com/wp-login.php.
Enter credentials — you should land on /wp-admin/ with no error.
Confirm with WP-CLI: wp option get siteurl should return the exact URL you logged in from.
In DevTools → Application → Cookies, confirm wordpress_logged_in_* exists with the correct domain and Secure flag set.

Quick reference — most common fix by symptom

Works in incognito, fails in normal browser → clear cookies/cache, check extensions.
Fails on both http:// and https:// versions → URL mismatch in wp_options (Step 2).
Started after moving to a new host or adding SSL → COOKIE_DOMAIN mismatch or X-Forwarded-Proto missing (Steps 3–4).
Started after installing a plugin → plugin conflict (Step 5).
Set-Cookie header absent in DevTools → proxy/cache stripping cookies (Step 6).