Website Works in Chrome but Sometimes Loads Incorrectly in Microsoft Edge

The behavior can be caused by several Edge-specific features and differences, even though both browsers are Chromium-based. The following checks focus on what’s specific to Microsoft Edge.

1. Check if Tracking Prevention is affecting your site
   Edge’s tracking prevention can block scripts, iframes, pixels, or storage access for domains it classifies as trackers. This can cause layouts or functionality to break intermittently. Steps to investigate:
   1. Open the site in Edge.
   2. Select the page info icon (lock) in the address bar and review which trackers were blocked on that page.
   3. Open DevTools → Console and refresh the page.
   4. Look for messages like Tracking Prevention blocked access to storage for <URL>.
   5. If you see blocked URLs that belong to your own CDN or critical third-party services, that’s a strong indicator.
   For deeper inspection:
   • Use the disconnect.me services.json list to see how a blocked domain is categorized.
   • If needed for debugging, temporarily disable tracking prevention for your site via the page info flyout or edge://settings/privacy/trackingPreventionExceptions, then reload and compare behavior.
   • You can also use edge://settings/content/cookies to explicitly Allow or Block specific domains’ storage and see if that changes the layout/behavior.
2. Consider Org Relationship / Org Engagement mitigations
   If your site uses a CDN or multiple domains under the same organization, Edge may relax tracking prevention between those domains using the Org Relationship mitigation. If some resources are served from domains not recognized as part of the same organization, they may still be blocked, leading to partial or inconsistent loading. Recommendations:
   • Ensure critical resources (CSS/JS) are served from domains clearly associated with your main site (ideally same-site or same-org).
   • If you rely on third-party trackers or analytics that also serve layout-critical scripts, separate layout/functional scripts from tracking scripts so that blocking trackers does not break layout.
3. Check for site-impacting platform changes in Edge
   Edge sometimes defers or modifies certain Chromium web platform changes. These can affect layout or script behavior differently than Chrome. Actions:
   • Review the “Site compatibility-impacting changes coming to Microsoft Edge” documentation to see if any high-impact changes match technologies used on your site (HTML/CSS/JS features, security changes, etc.).
   • If you’re using newer or experimental web platform features, test with and without flags in Edge to see if a specific feature is causing issues.
4. Use proper detection patterns (avoid UA sniffing differences)
   If the site uses user-agent detection to serve different code paths, Edge may be getting a different bundle or CSS than Chrome. Guidance:
   • Prefer feature detection over user-agent checks.
   • If user-agent-based logic is unavoidable, use User-Agent Client Hints and generic Chromium detection instead of hard-coded browser names.
   • Example pattern to detect Chromium-based browsers:

          function isChromium() {
            for (brand_version_pair of navigator.userAgentData.brands) {
              if (brand_version_pair.brand == "Chromium"){
                return true;
              }
            }
            return false;
          }
     

   • Avoid branching specifically on Microsoft Edge vs Chrome, which can lead to one browser getting outdated or incomplete code.
5. Debug with cache/cookies and extensions in Edge
   Even though this is similar to Chrome troubleshooting, Edge’s tracking and privacy model can interact with cache and extensions differently. Steps:
   1. Open an InPrivate window in Edge (no extensions by default) and load the site. If the layout is stable there, extensions or cached data in the normal profile are likely involved.
   2. Clear Cookies and other site data and Cached images and files for your domain, then retest.
   3. If tracking prevention messages disappear or behavior stabilizes after clearing, adjust your site’s reliance on third-party storage or trackers.
6. Check for known Edge issues if behavior started recently
   If the problem appeared after a specific Edge update, compare against the known issues list for that version, especially if your site uses PDFs, HTTP cache heavily, or custom start-page-like behavior.
   • For example, some Edge versions had issues with HTTP cache causing pages to fail to fully load (net::ERR_FAILED), which could manifest as incomplete or broken layouts. These are fixed in later stable releases.

Summary of recommended debugging path:

1. Use DevTools Console in Edge to look for “Tracking Prevention blocked access to storage” messages and blocked resource loads.
2. Temporarily disable tracking prevention for your site and compare behavior.
3. Ensure no Edge-specific user-agent branching is serving different CSS/JS than Chrome.
4. Test in InPrivate (no extensions) and with cleared cache/cookies.
5. Review Edge’s site-impacting changes and known issues if the problem is tied to a specific version.

References:

• Tracking prevention in Microsoft Edge
• Detecting Microsoft Edge from your website
• Site compatibility-impacting changes coming to Microsoft Edge
• Microsoft Edge known issues
• Edge-specific web development tips