Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The WordPress “Cookies are blocked or not supported by your browser” message usually means WordPress could not write or read its login cookies. It does not necessarily mean that you disabled every cookie in your browser. Start by allowing cookies for the site, clearing that site’s stored cookies, and retrying in a private window. If the error remains in every browser, check the site’s URL, HTTPS configuration, caching, plugins, and hosting layers.
WordPress tests cookie support with a temporary cookie named wordpress_test_cookie. A failed test, or an authentication cookie sent to the wrong host, path, or scheme, prevents wp-login.php from completing sign-in.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the WordPress cookie error actually means
Login requires WordPress to set cookies and receive them back on the next request. The first diagnostic is a temporary cookie called wordpress_test_cookie. WordPress Developer Resources explains: “WordPress will set a temporary cookie named wordpress_test_cookie which is to probe the ability of WordPress to set cookies. If writing this cookie fails, you will get the following error message ‘Cookies are blocked or not supported by your browser.’” That documentation was updated October 14, 2026.
After the test succeeds, WordPress uses authentication cookies to maintain the logged-in session. A browser can therefore have cookies enabled globally while still rejecting this particular cookie because an extension blocks it, the cookie belongs to another hostname, the path is wrong, HTTPS is inconsistent, or an intermediary returns a stale response.
The fastest fix depends on the failure’s scope:
| What you observe | Most likely layer | Best next check |
|---|---|---|
| The error appears in one browser only | Browser cookie policy, stored site data, or an extension | Allow cookies for the site, clear its data, and test privately or in another browser |
| The error appears in every browser | WordPress URL, HTTPS, cache, plugin, proxy, CDN, or server | Compare the site address with home and siteurl, then work through the server-side layers |
| It began after a migration or domain change | Hostname, path, scheme, or cookie-domain mismatch | Check www versus the apex domain, subdirectory paths, and HTTP versus HTTPS |
| It began after a security or login-plugin update | Plugin filtering or renamed-login logic | Temporarily disable the relevant plugin and test the standard login URL |
| It began after enabling SSL or a proxy | HTTPS termination, reverse-proxy, CDN, or cache rules | Make every layer agree that the public origin is HTTPS and that login responses are not cached |
Fix the browser before changing WordPress
Browser-side checks are quick and reversible. Perform them on the exact address you use to open the login page, including its hostname, port, path, and HTTPS scheme.
Allow cookies for the WordPress site
- Open the browser’s privacy or site-settings panel while viewing the WordPress site.
- Find the cookie setting for the current site and allow cookies, at least for that site. Browser labels vary; look for “Cookies,” “Site data,” or “Permissions.”
- Close the login tab, open a new tab, and visit the same login address again.
Do not assume that enabling a global cookie setting fixes a site-specific block. A per-site exception, strict privacy mode, or an enterprise policy can override the global setting.
Clear cookies and site data for only this domain
- Use the browser’s site-information control beside the address bar, or open the privacy settings and search for the site’s hostname.
- Delete cookies and stored site data for that hostname. If the site uses both an apex domain and a
wwwhostname, clear data for both. - Reload
wp-login.phpand sign in again.
Clearing the affected domain removes stale cookie values without requiring you to erase unrelated browsing data. You may need to sign in again to other services that share the same hostname.
Test a private window or another browser
Open a private or incognito window and try the same login URL. If that works, the normal profile has stale data, a restrictive setting, or an extension conflict. Testing another browser is useful for separating a local profile problem from a website problem.
Temporarily disable privacy and advertising extensions
Turn off ad blockers, tracker blockers, script controls, and privacy extensions for the WordPress site, then retry. If the login starts working, restore extensions one at a time until the failure returns. The last extension enabled is the likely source; keep it disabled for this site or add a narrowly scoped exception instead of weakening protection everywhere.
Confirm that every URL points to the same site
WordPress stores two important addresses: home, the public site address, and siteurl, the address where WordPress files and administration are installed. The browser address, those two values, and any redirect or proxy must agree on hostname, path, and scheme.
Check the address you are actually using
- Choose either the apex hostname or the
wwwhostname and use it consistently. A cookie issued for one host is not automatically available to the other. - Preserve the installation path. A site installed in
/blogmust not alternate between a root login path and a subdirectory login path. - Use HTTPS consistently after SSL is enabled. Do not switch between HTTP and HTTPS during the same login flow.
- Follow the site’s canonical redirect and then reopen the login page from that final address.
Migrations, domain mapping, and a change from www to the apex domain commonly leave one of these values behind. The result is a cookie sent to a host or path that the next request does not use.
Check the values in WordPress
If you can reach the dashboard through an existing session, open Settings > General and inspect WordPress Address (URL) and Site Address (URL). They should use the intended hostname, path, and HTTPS scheme. Save corrected values, then clear the site’s cookies and caches before trying again.
If you cannot reach the dashboard, the same values can be inspected in the site database or hosting control panel. Make a backup before editing database values, and change only the affected site’s records. A multisite installation has additional domain and path rules, so do not apply a single-site fix blindly.
Review cookie-related settings in wp-config.php
Open wp-config.php through SFTP or your host’s file manager and search for these definitions:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWP_HOMEWP_SITEURLCOOKIE_DOMAINCOOKIEPATHSITECOOKIEPATH
WP_HOME and WP_SITEURL should match the intended public configuration. If they force an old hostname, an old subdirectory, or HTTP instead of HTTPS, WordPress can issue cookies for the wrong scope.
Pay particular attention to COOKIE_DOMAIN. A stale value copied from a forum post can make the browser reject or omit the cookie. Remove an incorrect COOKIE_DOMAIN definition rather than guessing a replacement; the correct value depends on the host and, for multisite, the network layout. Likewise, do not alter COOKIEPATH or SITECOOKIEPATH unless you know the installation’s required path.
Rank #3
After saving a configuration change, clear the affected domain’s cookies and purge relevant caches. A configuration edit does not remove an already stored cookie with the wrong scope.
Make HTTPS consistent from the browser to the origin
Mixed HTTP and HTTPS settings can prevent the browser from accepting or returning the cookie WordPress expects. Check all parts of the request chain:
- The address in the browser should resolve to the intended HTTPS URL.
WP_HOMEandWP_SITEURLshould use HTTPS when the public site is HTTPS.- A reverse proxy or load balancer should pass the original HTTPS state correctly to WordPress.
- A CDN should use HTTPS to the visitor and the configured origin, according to the site’s deployment.
- Redirects should not bounce the login request between HTTP and HTTPS.
If SSL was recently enabled, change the URL configuration first, then purge caches and clear browser cookies. If a proxy terminates SSL before forwarding requests, ask the host to verify that WordPress is not being told that an HTTPS request is plain HTTP.
Bypass page caches and cookie-unaware CDNs
Login responses are specific to a visitor and must not be served from a generic page cache. Exclude wp-login.php, /wp-admin/, and requests that carry authentication cookies from page caching. Apply the exclusion at every layer that can cache HTML:
- A WordPress caching plugin
- The web server’s cache
- A reverse proxy
- A CDN or edge cache
Purge each cache after changing URLs, SSL settings, cookie rules, or plugin configuration. WordPress’s login guidance specifically recommends clearing cookies and server cache after moving a site. If only one cache is purged, another layer can continue returning the old login response or old redirect.
Do not cache the login form or an authenticated administration response. A cached response can make the problem appear intermittent: one request may reach WordPress and set a cookie, while the next request receives an older response without the expected cookie behavior.
Free tools Windows power users keep installed
One-click scans. No signup required.
Isolate plugins and the active theme
Security, login-renaming, cookie-control, and caching plugins can change headers or intercept login requests. Test them systematically rather than disabling everything permanently.
Disable plugins when dashboard access is unavailable
- Use SFTP or the host’s file manager to open
wp-content. - Temporarily rename the
pluginsdirectory, for example toplugins-disabled. This prevents WordPress from loading the installed plugins. - Open the standard
wp-login.phpaddress and test. - If login works, restore the directory name and reactivate plugins one at a time, testing after each activation.
A WordPress.org support case reported that disabling a security plugin’s rename-login feature fixed this error. If a renamed-login plugin is installed, confirm its configured login path and temporarily return to the standard path while diagnosing.
Test the active theme
If disabling plugins does not help, rename the active theme’s directory through SFTP or the host file manager. WordPress will fall back to an available default theme. Test the login, then restore the original directory and investigate theme code that modifies headers, redirects, or login hooks.
Re-enable components one at a time after the login works. The first component that brings the error back identifies the layer to configure or replace.
Escalate to the host when every browser fails
When the error survives private-window testing, a second browser, URL checks, cache purges, and plugin isolation, the remaining causes are often outside the WordPress dashboard. Ask the hosting provider or server administrator to inspect:
- The response headers for
Set-Cookie, including whetherwordpress_test_cookieis being sent. - Proxy, load-balancer, or CDN rules that strip, rewrite, cache, or block cookies.
- Domain-mapping rules that send the cookie to a different hostname or path.
- HTTPS termination and forwarded-protocol handling.
- Web-application-firewall or server filtering that modifies login responses.
Provide the exact login URL, the time of a failed attempt, whether the failure occurs in every browser, and any recent migration, SSL, domain, or plugin change. WordPress.org support identifies host-side cookie filtering as a possible cause, so the host may need to compare the response at the public edge with the response generated by the origin server.
Use the failure pattern to choose the next step
Only one browser fails
Stay in the browser layer: allow site cookies, delete the domain’s stored data, test privately, and disable extensions one at a time. Do not edit wp-config.php until another browser demonstrates the same failure.
Every browser fails, but the site works for visitors
Check home, siteurl, cookie constants, HTTPS consistency, and login exclusions in the cache. The public site can appear normal while the login endpoint is sending a cookie to the wrong scope or receiving a cached response.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The failure began immediately after a migration
Compare the old and new hostname, installation path, and scheme. Remove stale cookie-domain settings, update both URL values, clear browser cookies, and purge plugin, server, and CDN caches.
The failure began after a security-plugin change
Disable the plugin, test the standard login path, and reactivate it only after confirming its cookie, redirect, and renamed-login settings. If the error returns on activation, keep the plugin disabled while its configuration is corrected.
The error returns after an apparently successful fix
Check for a second cache or proxy layer, and verify that the browser remains on one canonical host and HTTPS scheme. A stale edge response or redirect can reintroduce the symptom after the origin has been corrected.
Verify the repair
- Clear cookies and site data for the affected host.
- Open the canonical HTTPS login URL in a private window.
- Confirm that the login page loads without the cookie warning.
- Sign in and open an administration page under
/wp-admin/. - Open a new administration tab and refresh it to confirm the session persists.
- Repeat once in a normal browser window after re-enabling approved extensions.
If the warning returns, record which browser, hostname, path, and scheme were used. That information distinguishes a local cookie policy from a site-wide scope or server problem.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Quick Recap
Common mistakes to avoid
- Assuming the message proves that all browser cookies are disabled.
- Switching between
wwwand the apex domain while testing. - Changing
COOKIE_DOMAINto a guessed value copied from an unrelated site. - Fixing the origin but leaving a CDN or server cache serving the old login response.
- Disabling every plugin without re-enabling them individually, which hides the component that caused the failure.
- Editing URL values without first backing up the database or configuration file.
- Testing only the public homepage instead of the login endpoint and an authenticated administration page.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
