How to fix “Cookies are blocked or not supported by your browser” in WordPress

The “Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress” error on the WordPress login screen almost never has anything to do with your browser’s cookie settings. The cause is usually server-side: a caching plugin serving a stale login page, a URL mismatch between WordPress settings and the domain you’re actually loading, or a stray blank line at the top of wp-config.php. We’ve worked through this error on more WordPress sites than we’d like to count. Below are the fixes we run, roughly in the order we run them, with the ones most likely to work for the average site listed first.

If you’re locked out and time is short, jump to Start here: four quick browser checks first. If those don’t help, work down the list.

Why WordPress shows this error in the first place

WordPress sets a small cookie called wordpress_test_cookie when you load the login page. When you click Log in, it checks that cookie came back. If it didn’t, WordPress assumes cookies aren’t working and shows the error instead of attempting to authenticate.

That logic is reasonable, but the wording is misleading. The error blames your browser. In our experience, the browser is the actual cause about one time in twenty. The other nineteen are something on the server: a plugin that shouldn’t be caching wp-login.php, a mismatched site URL after a migration, output being sent before WordPress can set headers, or a proxy stripping cookie headers on the way through.

There’s a variant of the same error worth flagging early: “ERROR: Cookies are blocked due to unexpected output. For help, please see this documentation or try the support forums.” That wording is a useful clue. It tells you the cause is on the server, and specifically that something is being printed before WordPress reaches its setcookie() calls. If you see that wording, skip ahead to the whitespace fix, since that’s by far the most common cause.

Start here: four quick browser checks

Before touching anything on the server, rule out the obvious. These four checks take about five minutes and resolve the issue maybe one time in five. Skipping them costs nothing if they fail, but it saves an hour of digging if one of them turns out to be the answer.

Do them in this order:

1. Hard-refresh the login page. On Windows, Ctrl+F5. On Mac, Cmd+Shift+R. This forces the browser to reload the page rather than reusing a cached copy, which sometimes fixes it instantly if the page itself was served from a stale cache.
2. Try a different browser entirely. If you’ve been hitting the error in Chrome, open Firefox or Edge and try to log in there. If the second browser works, the issue is browser-specific: an extension, a privacy mode setting, or a corrupt cookie store. If both browsers show the same error, it’s server-side and you can stop testing browsers.
3. Open an incognito or private window with extensions disabled. Browser extensions, especially privacy and ad-blocking ones, can quietly strip or block cookies. Private windows usually run without extensions, so a working private window narrows the problem to one of the extensions in your normal profile.
4. Clear cookies for the affected domain only. Don’t wipe everything; just remove cookies for the site you’re trying to log into. In Chrome, that’s chrome://settings/cookies, search the domain, click Remove all shown. Firefox, Edge and Safari all have equivalent screens. Old or corrupted cookies from a previous session or a previous host can stop new ones being set.

Some quick links to the relevant settings:

• Clear cookies in Chrome
• Clear cookies in Firefox
• Clear cookies in Safari
• Clear cookies in Edge
• Clear cookies in Samsung Internet

If none of the four browser checks helped, the cause is on the server. Keep reading.

A caching or security plugin is intercepting your login

This is the single most common server-side cause we see. WordPress caching plugins are supposed to leave the login flow alone, but if wp-login.php or wp-admin get included in the cache by mistake (often through a custom rule, a CDN page rule, or a careless setting), the test cookie either never gets set or gets stuck in cached output. Security plugins can do something similar by overriding cookie handling or applying session rules that don’t play well with WordPress core.

Common offenders we’ve seen cause this exact error:

• Caching plugins: WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, WP Fastest Cache, Hummingbird. WP Rocket’s own documentation notes that if you’ve changed the login URL away from the default and not excluded the new path from the cache, the login page will be cached and break.
• Security plugins: Wordfence, Kadence Security (formerly Solid Security, originally iThemes Security), Sucuri, All In One WP Security. These can interfere via firewall rules that strip cookies, geographic restrictions that block your IP range, or session management settings that conflict with WordPress core.

The fix is usually one of two things. Either temporarily deactivate the suspect plugin and try logging in again, or, if you can’t reach the dashboard to do that, rename the plugin’s folder via SFTP. Plugins live in /wp-content/plugins/. Renaming a plugin folder (for example, from wp-rocket to wp-rocket-off) deactivates it instantly without needing dashboard access. If renaming the suspect plugin’s folder lets you log in, you’ve found the cause.

Once you can log in, don’t just leave the plugin off. Configure it properly: exclude wp-login.php and any custom login URL from page caching, and add wp-admin/* to the cache exclusion list as well. If the issue is in a security plugin’s firewall rules, the plugin’s logs will usually show what it blocked, and you can whitelist the rule or your IP.

If you’d rather not get into plugin configuration files at this level, this is the kind of thing covered by an ongoing WordPress maintenance and support retainer: someone keeping an eye on plugin updates and exclusion rules so the login page doesn’t stop working after the next update.

WP_HOME and WP_SITEURL don’t match the URL you’re loading

Cookies have a domain attached to them. If WordPress sets the cookie for www.example.com but your browser is loading example.com (or HTTP versus HTTPS, or a different subdomain), the cookie is dropped silently and you get the cookies-blocked error. This is the second most common server-side cause we see, especially right after a migration, an SSL change, or a domain swap.

There are two URL fields in WordPress: WordPress Address (URL) and Site Address (URL). Both live under Settings → General in the admin. They can also be hard-coded in wp-config.php as WP_SITEURL and WP_HOME, in which case the database values are ignored.

If you can’t reach the dashboard, define them in wp-config.php directly. Open the file via SFTP or your host’s file manager, and add these two lines somewhere above the “That’s all, stop editing!” comment:

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

Replace the URL with the exact one your visitors load in the browser, including protocol and the www prefix (or not) consistently. The two values must be identical. If you’re using HTTPS, both should start with https://. If your canonical domain is www.example.com, both should include the www.

If you’ve recently swapped between HTTP and HTTPS, run a search-and-replace across the database to update any old URLs hard-coded in content. WP-CLI handles this cleanly with wp search-replace 'http://example.com' 'https://example.com', but use a database backup first. If you’re on a host that doesn’t give you WP-CLI access, the Search Replace DB tool from Interconnect IT does the same job from a single-file PHP script.

Whitespace or a BOM is breaking wp-config.php or functions.php

This is the cause behind the “Cookies are blocked due to unexpected output” variant of the error. WordPress can’t set cookies once it has already started sending content to the browser, and PHP starts sending content the moment anything appears outside a PHP tag. A blank line before <?php at the top of a file counts. A blank line after the closing ?> counts. A Byte Order Mark (BOM) at the start of a UTF-8 file counts, even though it’s invisible in most editors.

The two files where this most often happens are wp-config.php in your site root and functions.php in your active theme. Both get edited frequently, and both are sensitive to whitespace at the top or bottom.

To fix it:

1. Open wp-config.php in a proper code editor (VS Code, Sublime Text, Notepad++, or your IDE of choice; not TextEdit or Notepad, which can introduce odd characters).
2. Check the very first line is <?php with absolutely nothing before it. No spaces, no blank lines, no invisible characters.
3. If there’s a closing ?> at the bottom of the file, delete it along with anything after it. PHP files don’t need a closing tag, and not having one removes a whole class of whitespace problems.
4. Save the file as UTF-8 without BOM. In VS Code, click the encoding indicator in the bottom-right and choose UTF-8 (not UTF-8 with BOM). In Notepad++, go to Encoding → UTF-8.
5. Repeat the same check on wp-content/themes/your-theme/functions.php.

If the error message includes a file path and line number, look at that specific file first. WordPress will sometimes give you exactly the file responsible, for example output started at /wp-content/themes/your-theme/functions.php:1. Line 1 almost always means a BOM at the start of the file.

Saving files via WordPress’s built-in theme editor or plugin editor occasionally introduces this kind of issue, especially if you’re copy-pasting code from a forum or blog post that wrapped the content in invisible characters. We’ve stopped letting clients use the in-dashboard editor for this exact reason. SFTP and a real code editor is safer.

A plugin or theme is conflicting

Even when no single plugin is the obvious culprit, two plugins can conflict in ways that interfere with cookie handling. The same is true of themes, since a theme’s functions.php can hook into the login flow.

The standard troubleshooting move is to deactivate everything and re-enable one at a time. If you can reach the dashboard, that’s straightforward. If you can’t (because the cookies error is keeping you out), use SFTP:

1. Connect to your server and navigate to /wp-content/.
2. Rename the plugins folder to plugins-off. This deactivates every plugin in one move.
3. Try to log in. If it works, the issue is one of your plugins.
4. Rename the folder back to plugins. The plugins will still be deactivated in the database.
5. Reactivate them one at a time from the dashboard, testing the login each time, until you find the one that breaks it.

For themes, rename the active theme’s folder in /wp-content/themes/. WordPress will fall back to a default theme (Twenty Twenty-Four or similar). If you can suddenly log in, your theme’s functions.php is doing something to the login flow.

A common version of this conflict involves session management plugins (which try to force users to log in only once), security plugins (which add extra cookie checks), and translation or membership plugins (which sometimes hook into the auth flow more aggressively than they should). When you find the culprit, decide whether you actually need that plugin or whether a better-behaved alternative exists.

The .htaccess file is corrupted or has a bad rewrite rule

If you’re on Apache or a host that uses Apache rewrite rules (most shared hosting), .htaccess sits in your site root and controls things like pretty permalinks and redirects. A bad rule, a broken redirect, or an HTTP-to-HTTPS loop can prevent cookies from being saved correctly.

To rule it out, rename the file to .htaccess-old via SFTP. The site might lose pretty permalinks temporarily, but the login should still work. If the cookies error disappears, the file was the cause. Log in, go to Settings → Permalinks, and just click Save Changes without changing anything; WordPress will regenerate a clean .htaccess for you.

If you’ve added custom redirect rules to .htaccess (forcing HTTPS, redirecting www to non-www or vice versa), make sure they aren’t causing a redirect loop. Looping redirects don’t just look broken; they can prevent cookies from being saved at all because the browser never settles on a final URL.

You’re running WordPress Multisite and need COOKIE_DOMAIN set

If your site is a WordPress Multisite install, especially one using domain mapping, this error has a specific known fix. WordPress sets a default cookie domain based on the network’s primary URL. When you map a custom domain to a sub-site, the cookie domain doesn’t match the URL the visitor is loading, so the cookie is dropped.

The fix is to add this line to wp-config.php:

define('COOKIE_DOMAIN', false);

That tells WordPress to leave the cookie domain unset, which lets the browser figure it out from the request URL. The Plugin Republic write-up on this has a useful comment thread with people reporting which variant worked for their setup; on some networks define('COOKIE_DOMAIN', ''); works where false doesn’t, or vice versa.

If COOKIE_DOMAIN is already defined somewhere in your wp-config.php (or in a must-use plugin), WordPress will throw a “constant already defined” notice. In that case, find the existing definition and either change its value or comment it out before adding the new one.

Multisite networks bring a stack of edge cases the single-site install doesn’t have. If you’re running a network and the cookies error keeps recurring, the issue is often deeper than this one constant; cross-domain authentication on multisite is genuinely finicky. This is one of those situations where bringing in specialist WordPress recovery help can save days of guesswork.

Cloudflare or another reverse proxy is interfering

If your site sits behind Cloudflare, AWS CloudFront, a Sucuri WAF, or any other reverse proxy, the proxy has the chance to mess with cookies on the way through. We see this in two main ways.

SSL mode mismatch. Cloudflare has an SSL setting called Flexible that serves your site over HTTPS to visitors but talks to your origin server over plain HTTP. Unless the proxy headers are handled correctly, WordPress can see the request as plain HTTP and behave accordingly: generating redirects to the wrong scheme, setting cookies with the wrong attributes, and producing a login flow where the browser never settles on a single secure URL. Cloudflare’s own documentation flags redirect loops as a known symptom of Flexible mode when the origin forces HTTPS. The fix is to switch to Full (Strict), install a valid certificate on the origin, and make sure WordPress correctly recognises HTTPS behind the proxy (usually by trusting the HTTP_X_FORWARDED_PROTO header in wp-config.php).

Cached login page. Cloudflare’s default page rules don’t cache HTML, but if you’ve added a page rule or a Cache Rule that includes wp-login.php or the wp-admin path, the same problem we covered above for plugin-based caching applies. Add an explicit exclusion: cache everything else, but bypass cache for */wp-login.php* and */wp-admin/*.

SameSite and the cf_clearance cookie. Cloudflare’s clearance cookie is normally set as SameSite=None; Secure when your site is fully on HTTPS. If HTTP is used anywhere on the site, Cloudflare’s documentation says the cookie can default to SameSite=Lax, which may cause the site to behave unpredictably. Moving the whole site to HTTPS keeps this predictable. Mixed-content sites are a common source of cookie weirdness.

If you’re using a custom Nginx reverse proxy in front of WordPress, check that Set-Cookie headers from the upstream aren’t being stripped or rewritten. The proxy_pass_header Set-Cookie directive should be left alone, and proxy_cookie_path rules should match your actual paths. This is the kind of detail that lives in how WordPress hosting is set up rather than in WordPress itself.

You’re loading wp-admin inside an iframe

Some SaaS dashboards, site-builder previews and white-label management tools embed WordPress admin screens inside an iframe on a different domain. In a modern browser, this is a structural problem for the login cookie.

Browsers default to SameSite=Lax on cookies that don’t explicitly set the attribute. A Lax cookie is only sent on top-level navigations, not on requests made from inside an iframe on a different domain. The login POST happens inside the iframe, the test cookie is “third-party” from the browser’s point of view, and the cookie gets dropped. You see the cookies-blocked error.

The clean fix is to open wp-login.php in a top-level tab rather than inside the embed. Once you’ve logged in there, you can return to the embed and your authenticated session will usually carry through. If you’re the developer of the wrapping application, you can sometimes work around this by setting SameSite=None; Secure on the WordPress auth cookies, but that requires HTTPS everywhere and brings its own privacy considerations. MDN’s SameSite reference covers the trade-offs.

Strict browser privacy mode or an aggressive extension

This is what the error message blames first, and occasionally it’s right. Worth checking after you’ve ruled out the server-side causes.

Common offenders:

• Brave’s Shields at the Aggressive setting blocks cookies that other browsers wouldn’t.
• Firefox’s Strict Enhanced Tracking Protection can interfere with cookies from sites it categorises as trackers, occasionally including your own.
• Safari’s Prevent cross-site tracking applies the same logic.
• uBlock Origin’s cosmetic filters, when overly aggressive, can affect login form behaviour even though they’re meant for ads.
• “Delete cookies on exit” profiles in Firefox and other browsers can wipe the test cookie between the page load and the form submit if a tab close happens in between.

If your everyday browser has any of these enabled, add an exception for your own site or temporarily relax the setting to confirm whether it’s the cause. One thing to keep in mind: Chrome’s third-party cookie deprecation, which spent years being threatened, was officially abandoned by Google on 22 April 2025. Chrome now lets users manage cookies through existing privacy settings rather than blocking them by default. So as of 2026, Chrome’s defaults are unlikely to be your problem unless an individual user has explicitly tightened their settings. WordPress login cookies are first-party anyway, which makes the wider third-party cookie debate largely irrelevant to this specific error.

The “force the test cookie” snippet (last resort)

If you’ve worked through everything above and the error still fires, you can force WordPress to set its test cookie from your theme’s functions.php. This is the fix from the original version of this article. It still works, but treat it as a workaround rather than a real solution; if you’re using it, something else is wrong and worth tracking down properly.

Open wp-content/themes/your-active-theme/functions.php and add the following inside the existing PHP block, near the bottom but before any closing ?> (if there is one):

setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH ) {
    setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}

Save the file. The original suggestion comes from a WordPress Support Forum thread by mirajas and forces the cookie WordPress is looking for to be set on every page load, regardless of the normal flow.

A few things to watch for:

• If your theme is updated by its developer (most paid themes are), you’ll lose this change on the next update. Put it in a child theme’s functions.php instead, or in a tiny custom plugin, so it survives updates.
• Edit the file via SFTP, not WordPress’s built-in theme editor. The built-in editor can introduce whitespace or BOM characters and create exactly the problem this snippet is trying to work around.
• If this snippet “fixes” the issue, it usually means the underlying cause is one of the earlier ones (caching, URL mismatch, whitespace), and you’re papering over it. It’s worth circling back to find the real cause when you have time.

When you’ve tried everything and nothing works

At this point the issue is almost certainly something specific to your setup: a custom plugin doing something unusual, an aggressive WAF rule, a host-level mod_security configuration, or a deeper authentication conflict. Generic guides stop being useful around here.

A few things that help when you call in someone to look at it:

• Note the exact error wording. “Cookies are blocked or not supported by your browser” and “Cookies are blocked due to unexpected output” point to different root causes.
• Open browser developer tools, go to the Network tab, attempt to log in, and check the response headers on the POST to wp-login.php. The presence or absence of Set-Cookie in the response tells you a lot.
• Check your hosting control panel for PHP error logs. If WP_DEBUG isn’t on, turn it on temporarily and watch /wp-content/debug.log.
• If you’re behind Cloudflare or another proxy, note the SSL mode and whether you have any active page or cache rules.

The reason this error has such a long list of possible fixes is that “WordPress can’t set a cookie” is a symptom with at least ten unrelated causes. Once you’ve gone through the obvious ones, narrowing it down further usually means looking at server logs, header captures, and the specific plugins running on the site.

If you’ve worked through this list and the login is still broken, our team handles this kind of recovery work as part of WordPress fixes and recovery. We get sites back into the dashboard, then find the actual cause so it doesn’t happen again. Many fixes are quick once we can see the site, server and plugin setup.

Quick reference: which fix to try first

If you came to this article in a hurry and want a one-line summary of where to start, here’s the order we run through on a typical job:

1. Hard-refresh, try a different browser, try incognito, clear cookies for the domain.
2. Check the exact error wording. “Due to unexpected output” sends you straight to the whitespace fix.
3. Deactivate caching and security plugins (via SFTP if locked out).
4. Check WP_HOME and WP_SITEURL match the URL you’re loading.
5. Inspect wp-config.php and functions.php for whitespace and BOM.
6. Deactivate all other plugins, then your theme, by renaming folders.
7. Rename .htaccess to rule it out.
8. If multisite: add define('COOKIE_DOMAIN', false); to wp-config.php.
9. If behind Cloudflare: check SSL is Full (Strict), exclude wp-login.php and wp-admin from cache.
10. If embedded in an iframe: open the login in a top-level tab.
11. Force the test cookie via functions.php as a last-resort workaround.

Nine times out of ten, one of the first five fixes does it. If you’re stuck past number five, the issue is probably worth a second pair of eyes rather than another hour of trial and error.

Need a hand?

If you’d rather not spend the rest of your day inside wp-config.php, our WordPress team can sort this out for you. We work with sites of every size, from school websites and charities to high-traffic WooCommerce stores, and we can usually get to the bottom of a cookies-blocked error quickly once we can see the setup. Get in touch via our WordPress fixes and recovery page and we’ll take a look.