ERROR · 24 · VERIFIED 2026-10allwpcare.com/errors/cookies-are-blocked-or-not-supported-by-your-browser/
Errors / cookies-are-blocked-or-not-supported-by-your-browser

Cookies Are Blocked or Not Supported by Your Browser (WordPress Login)

WordPress did not get its test cookie back. Allow cookies for the site, open the exact Site Address, or fix COOKIE_DOMAIN and the login cache.

The message you see
1−Error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.
Last verified Oct 2026Tested with WordPress 7.1Applies to WordPress 7.1 (tested) · PHP 7.4+

Why it happens

  • The browser blocks cookies for the site, in its settings or through an extension. This is the case the message describes.
  • You opened the login page on a different host from the one in Settings → General → WordPress Address and Site Address, for example example.com when the site uses www.example.com. The test cookie is stored for one host and the form posts to the other.
  • COOKIE_DOMAIN in wp-config.php names a domain that does not match the address in the browser. The browser throws the cookie away.
  • A cache, CDN or proxy serves wp-login.php without its Set-Cookie header, so the test cookie never reaches the browser.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

FIX 01

Open the login page on the exact Site Address

  1. Look at Settings → General, or run wp option get siteurl if you cannot log in. Type that address, with or without www, exactly as shown, and add /wp-login.php.
  2. Why: the login form always posts to the Site Address. If you opened another host, the test cookie sits on that host and is not sent along. I reproduced it with the site set to www.lab.test and the login page opened on lab.test. The same message appeared. Opening www.lab.test logged in at once.
FIX 02

Allow cookies for this site in the browser

  1. Open the login page in a private window with extensions off. If it works there, an extension or a saved setting is the cause.
  2. In your browser's cookie settings, switch off "block all cookies", or add your site to the list of sites that may always use cookies. The menu names change between browsers, so use the enable cookies link in the error itself, which goes to the WordPress guide.
  3. I tested this in Chrome with cookies blocked for every site: the error appeared and no cookie was stored. After adding the site to the allowed list, login worked.
  4. Blocking only third-party cookies is not the cause. In my test Chrome with that setting still logged in, because the login cookie belongs to the site itself.
FIX 03

Remove or correct COOKIE_DOMAIN

  1. Open wp-config.php and find a line like define( 'COOKIE_DOMAIN', 'example.com' );.
  2. Delete the line, or set it to your site's own host name, or to its parent domain. With WP-CLI: wp config delete COOKIE_DOMAIN.
  3. Why: when COOKIE_DOMAIN is empty, WordPress sends no Domain attribute and the browser keeps the cookie for the exact host. When you set it, the browser accepts it only if it is the current host or a parent of it. I set it to example.com on a site at localhost: the header read domain=example.com and the browser discarded the cookie. Setting it to localhost fixed it.
  4. A value of www.example.com works on www but fails on the bare example.com. A value of example.com works on both.
FIX 04

Keep wp-login.php out of the cache

  1. In your caching plugin, CDN or host cache, add /wp-login.php and /wp-admin/ to the pages that are never cached. Then purge the cache.
  2. Check with curl -si https://example.com/wp-login.php | grep -i set-cookie. A working page prints Set-Cookie: wordpress_test_cookie=WP%20Cookie%20check. No line means something is removing it.
  3. I could not test a real CDN. I simulated one with Apache's Header unset Set-Cookie for wp-login.php: the login page loaded, no cookie was set, and the error appeared. Removing the rule fixed it.
FIX 05

If the message says "unexpected output"

  1. That is a different message with a different cause: a file printed text before WordPress could send its headers. See headers already sent for how to find the file and line.
  2. In short: remove the blank line or space before <?php in wp-config.php, or the byte order mark, or any stray echo.

WordPress sets a small test cookie when the login page loads. When you press Log In, it checks that the browser sent the cookie back. If it did not, WordPress cannot trust that a login cookie would survive either, so it shows this message. The browser is not always at fault. The same host name, the COOKIE_DOMAIN setting and a cache in front of the site all cause it.

What you see#

The message appears on the login screen after you press Log In. The form is empty again and the username is not kept.

The WordPress login screen. A red-edged notice above the form reads: Error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress. The words enable cookies are a link.
The message on WordPress 7.1.4, in Chrome with cookies blocked. Core prints the words enable cookies as a link.

How the check works#

In wp-login.php, WordPress sends wordpress_test_cookie on every page view of the login screen. The login form carries a hidden field, testcookie=1. On the login request, WordPress decides in this order:

  1. If it sent no login cookie because output had already started, it shows the unexpected output message.
  2. Otherwise, if the form said testcookie=1 and the request has no wordpress_test_cookie, it shows this message.
Five stacked steps. 1: the login page sets a test cookie. 2: the browser stores it or refuses it. 3: the form posts to the Site Address with testcookie=1. 4: WordPress checks for the test cookie. 5: the message is shown, whatever the password was.
Three of the five steps can fail. A cache breaks step 1, the browser or COOKIE_DOMAIN breaks step 2, and the wrong host breaks step 3.

Here is a normal login page, with the cookie in the headers:

Terminal
curl -si http://localhost:8904/wp-login.php | grep -i "^HTTP\|set-cookie\|cache-control"
Output
HTTP/1.1 200 OKCache-Control: no-cache, must-revalidate, max-age=0, no-store, privateSet-Cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; HttpOnly

The message hides the real error#

The check runs before WordPress reports a bad password. With no cookie jar, curl got the same message for all of these:

Login sentMessage shown
Correct user and password, testcookie=1, no cookieCookies are blocked or not supported by your browser
Wrong password, testcookie=1, no cookieCookies are blocked or not supported by your browser
Unknown user, testcookie=1, no cookieCookies are blocked or not supported by your browser
Wrong password, no testcookie fieldThe password you entered for the username admin is incorrect

The last row shows that a login form from a plugin that leaves out the testcookie field never gets this message. Also note the first row: WordPress had logged the user in and sent the login cookies. It still shows the error, and a browser that blocks cookies discards them. So you cannot tell from this screen whether your password was right. Once the cookie problem is fixed, a wrong password gives the password you entered is incorrect instead.

What each cause looks like#

I tested each cause on a lab site, in Chrome driven by Playwright.

CauseTest cookie after loading the login pageResult of Log In
Normalwordpress_test_cookie storedLogged in
Chrome blocks all cookiesnoneThis message
Third-party cookies blocked onlystoredLogged in
COOKIE_DOMAIN = example.com on localhostnone (header said domain=example.com)This message
COOKIE_DOMAIN = www.lab.test, page opened on lab.testnoneThis message
No COOKIE_DOMAIN, site at www.lab.test, page opened on lab.teststored for lab.test onlyThis message
Set-Cookie removed from wp-login.php by the servernoneThis message

Cookies are blocked due to unexpected output#

A second message uses almost the same words: "Error: Cookies are blocked due to unexpected output. For help, please see this documentation or try the support forums." It means PHP had already printed something, so the headers could not be sent. I made it by putting one blank line before <?php in wp-config.php. The login page then set no cookie at all, and logging in showed this message. Removing the blank line fixed it. The mechanism, the hunt for the file and the byte order mark are all in headers already sent.

When it is not this error#

If the login works but you land on the login page again with no message, that is a redirect loop, not a missing cookie. See too many redirects. If the reset email link ends on a login page, see your password reset link appears to be invalid: it needs cookies too. If you moved the login address with a plugin and forgot it, see the login URL guide.

Sources

  1. WordPress cookies (Advanced Administration Handbook) · the test cookie and how to enable cookies
  2. wp-login.php in WordPress core (trunk) · where the test cookie is set and where the message is chosen
  3. PHP: setcookie · the domain parameter, and that cookies are headers sent before output
  4. MDN: Set-Cookie header · host-only cookies and why a mismatched Domain is ignored
Newsletter

One email when something breaks or changes.

New plugins and re-tested guides, about twice a month. Never a sales pitch.