Fixing the Cookies Are Blocked Login Error
The browser is almost never the problem. WordPress sets a test cookie on the login form and looks for it on submit, and anything that changes the domain between those two requests — a URL mismatch, a cache, a proxy — makes the cookie vanish.
The message blames the browser; the cause is nearly always the server side of two requests. When wp-login.php renders the form it sets a cookie named wordpress_test_cookie and a hidden testcookie field. When the form is submitted with that field, it checks for the cookie. "Error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress." is printed when the cookie did not arrive. A sibling message, "Cookies are blocked due to unexpected output.", means something else entirely — PHP output before headers — and is covered under headers already sent. The rest of this page is about the first one, which is printed when the cookie did not arrive — and a browser with cookies enabled still will not send a cookie for a different host, from a page that never set one, or through a proxy that dropped it.
The three requests to think about
- The browser requests the login form and receives
Set-Cookie: wordpress_test_cookie. - The browser submits the form, sending cookies for the host the form is on.
- WordPress, on the host the form posted to, checks for the cookie.
Any difference between the host in step 1 and the host in step 3 breaks the chain. Any cache serving step 1 without the header breaks it. Any layer between the browser and PHP that strips cookies breaks it.
Cause 1: a URL mismatch
The form is served at one address and posts to another. The usual pairs are www and the bare domain, http and https, and a site moved to a new domain whose siteurl option still holds the old one. The form's action is built from site_url(), so if you opened the login at https://www.example.com and siteurl is https://example.com, the form posts across hosts and the cookie stays behind.
Check Settings › General, or the siteurl and home options directly, and make them match the address you actually use, including the www and the scheme. If the admin is unreachable, WP_HOME and WP_SITEURL in wp-config.php override the database until you can fix it. A redirect from one host to the other at the web server level is the permanent fix, so the mismatch can never recur.
Cause 2: the login page was cached
A page cache that stores wp-login.php serves the form without the Set-Cookie header. The first login attempt fails with this message; the failed request bypasses the cache, sets the cookie, and the second attempt works. That pattern — fails once, then works — is diagnostic.
Every cache plugin excludes wp-login.php by default, so the cache in question is usually a host-level or CDN cache with a rule that caught the page, or a plugin with its exclusions reset. Add the exclusion, purge the cache, and test in a private window.
Cause 3: COOKIE_DOMAIN
wp-config.php may contain:
define( 'COOKIE_DOMAIN', 'www.example.com' );
If the site is now served at example.com, cookies scoped to www.example.com are never sent to it, and the login fails every time. Remove the constant unless the site genuinely needs cookies shared across subdomains, in which case the value should be the parent with a leading dot: .example.com. On a subdomain multisite the network code defines it when nothing else has, and a sunrise.php that sets it first is the supported way to override.
Cause 4: a proxy or security layer
A reverse proxy, a CDN in front of the origin, or a web application firewall can strip or rewrite cookies. Cloudflare's own rules do not drop cookies by default, but a cache rule that caches everything including the login page reproduces cause 2, and some "optimise HTML" settings interfere with the form. Security plugins that rename the login URL run the login through a different path and can lose the cookie in the redirect. Disable them one at a time, in the order of plugin conflict testing, and retest after each.
Cause 5: the browser, finally
If every cause above is excluded, test in a private window with extensions disabled. Browser settings that block third-party cookies do not affect a first-party login, but a site opened inside an iframe — a site builder's preview, a management panel — is third-party from the browser's view and the cookie is refused. Open the site directly.
Verify
Open the login form in a private window, then check the response headers for Set-Cookie: wordpress_test_cookie=WP%20Cookie%20check. If it is absent, the page came from a cache or a proxy removed it. If it is present and the login still fails, compare the form's action URL with the address bar; they must share scheme and host. Once they match and the header is there, the login succeeds on the first attempt. If it instead loops back to the form with no error, that is the login redirect loop, which shares the URL cause and has its own extra ones.
Frequently asked
- Because the test cookie WordPress set on the login form did not come back with the submitted form. The browser sent cookies for the domain it was on; if the form posted to a different host, a cached copy of the form was served, or a proxy stripped the cookie, WordPress sees none and reports the browser.
- The first form was served from a page cache, with no Set-Cookie header, so no test cookie was set. The failed login bypasses the cache for the retry, which sets the cookie, and the second attempt succeeds. Exclude wp-login.php from caching.
- Only when the login form and the admin are on different hostnames that share a parent domain, such as www and the apex. Set it to the shared domain with a leading dot. On a site with one hostname, a wrong COOKIE_DOMAIN is a cause of the error, not a fix.