WordPress Not Working in One Browser

Start by locating the fault. "The site is broken in Chrome" is usually one of four different problems, and four quick tests separate them before you change anything.

If it fails everywhere, this is not a browser problem — go to WordPress site not loading or wp-admin not working instead.

Extensions are the most common cause

Ad blockers, privacy extensions, script blockers, password managers and translation tools all modify pages before you see them. On a WordPress site they typically break: the block editor, media uploads, page-builder canvases, embedded maps, payment fields and anything loading in an iframe.

Test properly rather than by guessing which one:

1. Open a private window. Most extensions are disabled there by default.
2. If that works, disable every extension in the normal window and confirm the problem disappears.
3. Re-enable in batches, not one at a time, until it returns.

An ad blocker filtering a script called analytics.js or a URL containing ads is a routine cause of a broken admin screen, and nothing in your logs will mention it.

Clear the right cache

There are three layers and they are not interchangeable:

• Browser cache — affects only you. A hard reload usually bypasses it; clearing site data resets it properly.
• Site cache — page cache plugin, object cache, host cache. Affects everyone. See how to clear the WordPress cache.
• CDN cache — sits in front of the site and survives both of the above.

When only one browser is stale, clear that browser's data for the site. When everyone is stale, clearing your own cache proves nothing — purge the site and the CDN.

Cookies deserve their own mention. A stale authentication cookie produces exactly the "I get logged out immediately" symptom in one browser only, and it is also a frequent cause of the login redirect loop. Clear cookies for your domain specifically rather than wiping everything.

Safari-specific failures

Safari is stricter than Chrome in ways that surface as "only Safari is broken":

• Certificate chains. Safari rejects an incomplete chain that Chrome accepts because Chrome will fetch the missing intermediate. If Safari alone reports a certificate problem, the server is not sending the full chain — the host fixes that. Related symptoms are in the WordPress "not secure" warning.
• Third-party cookie restrictions. Anything authenticating inside an iframe — an embedded checkout, an admin panel in a frame, some analytics — can fail in Safari and work in Chrome.
• Newer CSS. A layout feature supported in current Chrome may be missing from the Safari version on an older macOS or an iPhone that cannot update. That produces a broken layout in Safari only; site not displaying correctly on mobile covers how to narrow it down.
• Autoplay and media policies, which stop background video that plays fine elsewhere.
• Aggressive back/forward caching, which can show a stale logged-in header after logout.

"It only breaks on my Mac"

Almost always the machine, not the operating system:

• A system-wide DNS entry or an old /etc/hosts line pointing at a previous server. Check it if the site loads on the phone but not the laptop.
• A VPN, corporate proxy or security suite intercepting HTTPS.
• A clock that is significantly wrong, which invalidates certificates.
• Content blockers installed at the system level rather than in the browser.

Test the same page from another network — tethering to a phone is the fastest check — before touching the site.

When one browser really does see a different site

Two server-side causes produce genuine per-browser differences:

Caching keyed on user agent or device. Some caching and mobile plugins store separate variants. A corrupt variant means one class of visitor sees a broken page and everyone else is fine. Purge all variants and retest.

Server-side device detection in a theme or plugin, serving different markup by user agent. Compare the raw HTML in both browsers — view source, not the inspector, which shows the DOM after JavaScript has run. Different source means the server made a decision; identical source means the difference is in rendering or script execution.

Read the console before changing anything

Open developer tools in the failing browser and reload. The console names the file and line for JavaScript errors, and the network panel shows what was blocked or failed. Three patterns cover most cases:

• Blocked by the client → an extension or a content blocker.
• Mixed content, blocked → an HTTPS page requesting HTTP assets, fixed in mixed content warnings.
• A script error in one file → usually a plugin conflict or a broken minified bundle from an optimisation setting; how to fix plugin conflicts is the process.

An error that appears in every browser but only breaks one of them is still worth fixing — different browsers recover from the same bad JavaScript differently.

If nothing local explains it

Only now change the site. Take a backup, then disable JavaScript minification, combination and deferral in your optimisation plugin. Those three settings cause more browser-specific breakage than everything else combined, because a bundle that a forgiving parser tolerates will stop another one dead. Re-enable them individually afterwards.

Then check the site in the browser that failed, in a private window, on a second machine. If it now works everywhere, the optimisation setting was the fault — leave it off, or scope its exclusions properly rather than turning it back on and hoping.