Cookies are blocked or not supported in WordPress

Can’t log in to WordPress because of a cookie error? You’re not the only one. Many WordPress admins run into the message that cookies are blocked when trying to log in to wp-admin. You often see the warning: “Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.” This means WordPress can’t set or read the required login cookie. As a result you get stuck on the login screen or end up in a login redirect loop without reaching the dashboard.

In this knowledge‑base article I explain what cookies and sessions do in the WordPress login system, why this problem happens, and how you can resolve it in broad lines. This article is specifically aimed at site owners who can’t log in to the WordPress admin (not at site visitors). Don’t worry: your site itself usually remains accessible for visitors — this issue typically affects only the admin side.

What do cookies and sessions do during WordPress login?

When you log in to WordPress, the system uses cookies to manage your session and keep you logged in. Think of a cookie as the short‑term memory of your site: as soon as you log in, WordPress places a small text file (cookie) in your browser that effectively says “This user is logged in and authorized.” On every subsequent click or page request, WordPress checks that cookie to remember who you are without asking you to introduce yourself again. In other words: the cookie acts as your session identifier. Without it, WordPress “forgets” who you are on every page load, so you can’t stay logged in. WordPress relies on these cookies for authentication and session management; they are essential for keeping your login status and granting access to the dashboard.

Some WordPress authentication cookies include wordpress_sec_[hash] and wordpress_logged_in_[hash] (which indicate your login and identity), and wp-settings-[uid] (for dashboard preferences). WordPress also places a temporary test cookie on the login page (such as wordpress_test_cookie) to check whether your browser accepts cookies. If WordPress notices that this test cookie can’t be set or read, it blocks the login and shows the blocked‑cookies error — a security measure to avoid a login attempt that cannot work.

Symptoms of cookie or session problems during login

How do you recognize that your login issue is actually caused by cookies or sessions? Common symptoms include:

• Error message on the login screen: You explicitly see “Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.” every time you try to log in.
• Login screen keeps refreshing: You enter your username and password, but after submitting you’re returned to the login screen without an error. WordPress won’t let you into the dashboard because the login cookie couldn’t be set or read (so the site thinks you’re not logged in).
• Redirect loop after login: You see an endless redirect between wp-admin and wp-login.php. For example: you log in, WordPress tries to send you to the dashboard, but immediately sends you back to the login form because the session isn’t retained. This pattern can point to a cookie that isn’t working — the site keeps treating you as logged out and keeps asking you to log in.
• Getting logged out constantly: In some cases the login seems to succeed, but as soon as you take the next action in the dashboard, you’re logged out or asked to log in again. This also indicates that WordPress can’t remember your session, usually due to a cookie problem.

In short, if “WordPress login doesn’t work” and you notice the symptoms above, there’s a good chance something is wrong with the cookies or session in the login system.

Possible causes of blocked cookies (WordPress login)

The blocked‑cookies error indicates the login cookie isn’t working properly. But what causes that? Ironically the message doesn’t always mean your browser is actually blocking cookies — often the cause is elsewhere in the chain. Below I cover the most common causes.

Browser settings and privacy extensions

A straightforward cause is that the browser itself blocks cookies. Modern browsers have stricter privacy settings. Sometimes a browser is set to reject cookies (fully or partially). If you’ve disabled all cookies, enabled strict tracking protection, or are using private/incognito mode, cookies can be blocked — private browsing modes often reject cookies after the session by default. Browser extensions aimed at privacy or ad‑blocking can also silently interfere with cookies. Some extensions aggressively block all cookies or flag specific cookies (like WordPress cookies) as “suspicious.” The result is that WordPress’ test cookie or login cookie doesn’t get through, and the site assumes your browser doesn’t support cookies.

Example: you use a browser like Brave, or you have strict cookie settings in Firefox. You try to log in, but after submitting your details you remain on the login screen. In that case your browser may be preventing the WordPress cookie from being set. The same can happen if you have a privacy extension that is slightly too strict. To rule this out, try logging in with another browser, in a normal (non‑private) session, or temporarily disable your extensions. If login works then, you know the cause was in your browser settings or extensions.

Security and cache plugins on your site

A less obvious but common cause is WordPress plugins, especially security plugins and caching plugins. These plugins are useful, but they can be overzealous and accidentally block normal cookie behavior.

Popular security plugins (such as Wordfence, Sucuri, iThemes Security, etc.) may restrict certain cookie activities or invalidate sessions for safety. Their intention is good — protect your site — but it can lead to even legitimate admins being unable to log in because the login cookie is blocked.

Caching plugins (for example WP Super Cache, W3 Total Cache) can also get in the way. If a cache plugin caches the login page or headers too aggressively, the browser might see outdated information and not receive the fresh cookie. Sometimes the login page is served from cache without the cookie header (Set-Cookie), or the post‑login redirect is mishandled, resulting in a failed session.

There are also plugins that interact with cookies, such as cookie‑consent plugins. While these usually only affect the front end, a misconfiguration can cause them to block the WordPress login cookie until “consent” is given — which is obviously problematic for admin login. This doesn’t happen often, but it’s worth considering if you installed such a plugin recently.

Example: you updated a security plugin and from that moment you can’t log in. Or you migrated your site to new hosting and enabled a cache plugin, and suddenly you see the cookie error. In these cases it’s likely a plugin is interfering with the login process. A plugin might disrupt cookie generation or expect an extra security cookie. The result: WordPress can’t set the standard login cookie correctly, which triggers the error.

Theme errors or unexpected output (code issues)

Sometimes the cause lies in your active theme or another code source that unintentionally breaks things. In particular, output can be generated in a theme file, plugin, or even in wp-config.php before WordPress sends cookies. This is a technical detail: cookies are sent via HTTP headers, and HTTP headers can only be sent before any HTML output. If a theme or plugin accidentally sends text or whitespace to the browser (for example an extra line break, a BOM character, or a debug message) before the login‑cookie header, it blocks cookie transmission. WordPress immediately detects that the test cookie is missing or the authentication cookie didn’t arrive, and shows the error that cookies are blocked “due to unexpected output.” This scenario can occur after editing critical files like functions.php or wp-config.php, or after installing/updating a plugin that outputs content directly.

Other code errors can also cause session problems. For example, a misconfigured header, a conflict between two plugins, or even a PHP error that interrupts the login routine. These are harder to trace but certainly happen.

Example: you manually added a line of code in wp-config.php or a theme function, and from that point on the cookie error appears. That change likely caused unintended output or a conflict that prevents cookies from being set. In that case the “broken” code is the culprit, not your browser. Reverting the change or activating a default theme can confirm this.

Domain, SSL, or server configuration (site migration, etc.)

Finally, server or configuration issues around your domain and URL can lead to blocked cookies. WordPress login cookies are domain‑bound. If the site URL or domain recently changed, or you migrated the site to another server while keeping the same domain, conflicts can appear between existing cookies and the new environment. For example, old browser cookies may point to a path or domain that is slightly different from what the new WordPress install expects, so the new cookie isn’t set or read correctly.

Common issues after a site migration include incorrect cookie paths, wrong domain settings, or SSL changes (HTTP → HTTPS) that affect cookie behavior. If you switched your site from http to https, WordPress marks the login cookie as “secure” (only accepted over HTTPS). If you still try to log in via http, the browser won’t accept the secure cookie — result: login fails. The reverse can also happen: if the site runs on https but somewhere the config still expects http, it can break. In WordPress Multisite setups with domain mapping, this issue also appears: when a subsite gets its own domain, the cookie setting must be adjusted. If not, WordPress “doesn’t see” the cookie on the new domain and you keep getting the error.

A reverse proxy, load balancer, or special server cache can also strip or block cookie headers, though less often. And using certain VPN or proxy connections when logging in can cause issues (for example if your company uses a proxy that filters cookies, or if your IP changes per request via a VPN, which some WordPress security settings don’t like).

Example: you migrated your site to a new host but kept the same domain. After the migration you can’t log in — every attempt results in the cookie error even though cookies are enabled in the browser. WordPress may still be looking for something from the old environment. Clearing old cookies in your browser can help so a “clean” login is possible. Another example: you enable SSL and from that moment you get the cookie message during login. In that case you need to make sure you actually log in via https and that the WordPress settings (WP_SITEURL/WP_HOME) match the URL you use. If there’s a mismatch, the cookie gets blocked.

Solutions: how to make login work again

Now that the possible causes are clear, what can you do as an admin to fix it? Because the problem differs per situation, this is mostly about systematically narrowing down where the bottleneck is. Below are high‑level directions (not every step is always needed):

• Check your browser settings: Make sure your browser allows cookies for your WordPress site. Try a hard refresh (Ctrl+F5 / Cmd+Shift+R) on the login page and clear your browser cache and cookies for the site. Then log in again. If you use a privacy extension or ad blocker, temporarily disable it and try again. You can also test in another browser or in incognito mode (note: incognito clears cookies after the session, but shouldn’t block login itself). If login works in one browser but not another, the issue is almost certainly the settings or extensions in that browser. Adjust those settings to allow cookies (first‑party cookies) and try again.
• Disable security and cache plugins (temporarily): Think back to whether the issue started after activating or updating a plugin (especially security or caching). If so, deactivate that plugin temporarily and test login again. Because you can’t access the dashboard, do this via FTP or your hosting control panel by renaming the plugin folder (for example wordfence → wordfence_old to disable Wordfence). If login works afterward, the plugin was the culprit. Consider reporting the issue to the plugin developer. For caching plugins, clear the cache and see if that helps, or disable the plugin temporarily. Also consider whether you have a cookie‑consent plugin that interferes; allow cookies there (for yourself) or test with it disabled. Note: don’t forget to re‑enable or replace disabled security plugins once you’re done — you don’t want to leave your site unprotected.
• Test with a default theme and inspect custom code: To rule out your active theme or custom code, temporarily switch to a WordPress default theme (for example Twenty Twenty‑xx) or disable your current theme (e.g., rename the theme folder via FTP). Try logging in again. If it works, there’s an issue in your previous theme (possibly a snippet that breaks cookies). You’ll need to debug that theme — think recent changes, extra spaces or lines outside <?php ?> tags, and so on. The same goes for any code snippets in wp-config.php or mu‑plugins: remove or comment them out temporarily and see if login works. The idea is to inspect any custom code that runs early in the load process. A single rogue space or BOM character can already be enough to break login.
• Check site address, cookies, and server settings: Verify that recent changes to the site URL, domain, or SSL configuration were applied correctly. Check the database or wp-config.php to confirm that WP_HOME and WP_SITEURL match the URL you use to log in. Inconsistent URLs (for example WordPress set to https://example.com but you try to log in via http://) lead to cookie problems. Make sure you use the correct URL (preferably always HTTPS if configured). For multisite/domain mapping: check whether domain mapping is correctly set; if not, adjust it — in some cases you need to disable the cookie‑domain setting so WordPress accepts cookies on the new domain. Also, if you migrated the site: clear old cookies in your browser for that domain and try again. This prevents an old cookie from blocking the new login. Finally, check whether any unusual server headers or proxies are interfering with cookies (this is rare, but for example a wrong HTTP response header or strict server security module could theoretically block the Set-Cookie header). In most cases you don’t need to change this, but it’s good to know if everything else fails.

By working through these steps systematically, you increase the chance of finding the cause without diving deep into code. Usually a calm elimination of factors — first the browser, then plugins, then theme/code, then server config — reveals the problem and helps you fix it.

Conclusion

A login problem with the message that cookies are blocked can be very frustrating at first, but with insight into how WordPress uses cookies it’s often solvable. I’ve shown that cookies are crucial for the “session” of a logged‑in user, and that many factors — from browser settings to plugin behavior and server configuration — can cause cookies to fail. By checking step by step where things go wrong (starting with your browser and ending with server settings) you can usually find and resolve the issue. The key is to stay calm and follow the logic: WordPress wants to set a cookie; where is that being blocked? Once you know that, you can take targeted action.