404 Not Found From Disk Cache | Cache Fix Checklist

A 404 not found from disk cache message means your browser reused stale saved data, so a hard reload plus cache clear fixes it.

You click a link you trust, and your browser flashes a 404. Then you open DevTools and see a strange detail beside the request: “from disk cache.” That combo feels wrong. A 404 is a server response, so why is your local cache in the mix?

This page gives you a clean path to fix it, without guesswork. You’ll start with two fast checks that solve most cases. Then you’ll move into the deeper causes: stale site data, service worker caches, DNS mix-ups, and browser extensions that quietly change requests.

What “From Disk Cache” Means In Plain English

When Chrome, Edge, or another Chromium browser shows “from disk cache” in DevTools, it’s telling you the browser satisfied the request using its HTTP cache, saved on your drive. That detail can show up on good responses, too. It’s not an error by itself. It’s a clue about where the response came from.

A 404 can appear beside that label when one of these things happens:

  • A stale 404 got stored — The site returned a 404 earlier, your browser cached it, and then replayed it even after the file came back.
  • A redirect chain changed — The site moved a resource, but your cache still points to the old path.
  • A service worker served the wrong thing — Some sites cache assets for offline use. If that cache holds an old response, it can hand it back instantly. Chrome’s own docs describe how Cache Storage works inside the Application panel, separate from the normal HTTP cache. Chrome DevTools Cache Storage.
  • An extension rewrote the request — Privacy blockers, script injectors, or VPN tools can change URLs and headers.

So, the goal is simple: force a fresh copy, then clear the layers that can replay stale data.

Know When The Label Is Normal

Seeing “from disk cache” with a 200 status often just means your browser saved a file and reused it to speed up the next load. If the page works and the status is not 404, you can treat the label as a note, not a problem. The trouble starts when the Network panel shows a cached 404 for a file that should exist now.

Do one clean verification run. Open DevTools, keep it open, then reload with the “Disable cache” option checked in the Network tab. This forces a network fetch while DevTools is open, which tells you whether the 404 is still real. You can then turn caching back on for normal browsing. Disable Cache With DevTools.

404 Not Found From Disk Cache On Chrome, Edge, And Firefox

If you’re seeing this in Chrome or Edge, the steps line up closely because both run on Chromium. Firefox shows different wording, but the same idea applies: a cached response can mask what the server would return right now.

Quick Fix Order That Saves Time

Try these in order. Stop when the issue disappears.

  1. Hard reload the page — Hold Shift and click Reload, or press Ctrl+F5 on Windows and Linux, or Cmd+Shift+R on Mac. This tells the browser to recheck assets instead of trusting cache metadata.
  2. Open a private window — Private mode starts with a clean session, which helps you confirm if stored data is the trigger.
  3. Test the URL in another browser — If it works elsewhere, you’ve narrowed it to local state.

One Table To Pick The Right Next Step

Where You See It Fastest Fix To Try If It Keeps Happening
Only on one device Hard reload Clear site data, then DNS flush
Only on one browser Private window test Disable extensions, reset cache
On every device Check the site URL It’s likely a server path or redirect issue

Signs The 404 Is Cached, Not Live

A cached 404 has a few tells. You’ll see it pop up in one browser while another browser pulls the file with no fuss. DevTools may show the request as “from disk cache” with no new network activity.

  • It loads in private mode — A clean session skips stored cookies and cached entries, so the request path changes.
  • Another device works — If your phone loads the same URL on the same network, the server is probably fine at that moment.
  • A hard reload flips the result — If Ctrl+F5 makes the 404 vanish, stale local data was in the way.
  • The URL recently changed — New builds and moved files can leave old paths cached until you clear them.

Once you know which bucket you’re in, the fixes get cleaner.

Clear The Right Cache Without Wiping Everything

Clearing “all browsing data” can feel like using a sledgehammer. You lose saved sign-ins, form data, and lots of small conveniences. In many cases, you only need to reset one site’s stored data.

Clear Site Data For One Domain

  1. Open Site Settings — Click the padlock icon in the address bar, then open Site settings.
  2. Remove Stored Data — Choose to clear data for that site. This removes cached files tied to the domain and resets cookies for that origin.
  3. Reload The Page — Load the page again and watch the Network panel to confirm the request now hits the network.

If you prefer a deeper reset, Chrome’s built-in steps for clearing cached files are similar across versions. Many IT teams publish the same steps, like this clear-cache walkthrough. Clear Chrome Cache Steps.

Disable Cache While You Test

If you’re stuck in a cached 404 loop, turning off cache for a minute can save time. With DevTools open, check “Disable cache” in the Network tab, reload, then watch the status code change from cached to live. Disable Cache In DevTools.

  1. Open DevTools — Press F12 or Ctrl+Shift+I, then click the Network tab.
  2. Tick Disable Cache — Keep DevTools open while you refresh.
  3. Reload Twice — The first reload repopulates resources; the second proves the page stays clean.

Check Service Workers And Cache Storage

Modern sites often register a service worker. It can intercept requests and serve files from Cache Storage, even when the normal HTTP cache is clear. This is a common reason the same 404 keeps showing up after you “cleared cache.”

In Chrome DevTools, you can inspect Cache Storage under the Application panel. The Chrome docs explain where to find caches and how to delete entries. Inspect Cache Storage.

Reset A Site’s Service Worker

  1. Open Application Panel — In DevTools, go to Application, then Service Workers.
  2. Unregister The Worker — Click Unregister, then refresh the page.
  3. Clear Cache Storage — Expand Cache Storage and delete caches tied to the site.

If the site is a progressive web app, it may be using a tool like Workbox to precache assets. Workbox precaching gives developers control over what gets cached and when it updates. If the cache manifest is stale, users can see old results. Workbox Precaching.

When You’re Not The Site Owner

You can’t fix a broken cache manifest from your side. You can still clear your local service worker and caches, then reload. If the issue returns on multiple devices, it’s time to treat it as a site-side problem and move to the last section of this page.

Rule Out Network Traps That Fake A 404

Sometimes the cache is innocent. The browser may be reaching a different server than you think, then caching that result. DNS changes, VPN routing, captive portals, and proxy settings can all feed you a response that looks like a missing page.

Quick Network Checks

  1. Switch Networks — Try mobile hotspot or a different Wi-Fi. If the error vanishes, your original network path is suspect.
  2. Turn Off VPN And Proxy — Disable them briefly and test again. Many 404 reports inside browsers trace back to routing tools.
  3. Flush DNS Cache — On Windows, run ipconfig /flushdns. On macOS, use the built-in DNS flush command for your version. Then restart the browser.

Microsoft’s Q&A threads on Edge cache issues often pair cache clearing with checks for proxy and DNS settings because the two can interact in messy ways. Edge Disk Cache Discussion.

Check For Extensions That Change Requests

If the issue disappears in a private window, extensions are a prime suspect. Disable them one by one, reload, and watch for the first clean response. Many browser troubleshooting guides recommend this because it isolates the change that caused the bad request path. Chrome Thread On 404 Troubleshooting.

  1. Open Extensions Page — Type chrome://extensions in the address bar.
  2. Disable One Extension — Reload after each change.
  3. Remove The Culprit — If one add-on triggers the 404, uninstall it or reset its settings.

If You Run The Site, Fix The Root Cause

If your visitors report 404 not found from disk cache across devices, don’t treat it as a browser quirk. It often points to a resource URL that changes without cache-busting, a bad redirect, or a cached 404 response that your server allowed to be stored.

Common Site-Side Causes

  • Files moved without redirects — Update internal links or add a 301 redirect from the old URL to the new one.
  • Broken cache headers — If you send long cache lifetimes for files that change, users keep stale paths. For assets, use hashed filenames so a new build uses a new URL.
  • Service worker caching a 404 — Review fetch handlers so they don’t cache error responses. Many offline setups should cache only successful responses.
  • CDN edge caching errors — Purge the asset on your CDN, then confirm the origin serves a 200.

A Clean Debug Routine For Developers

  1. Reproduce With Cache Disabled — In DevTools Network, disable cache and reload to see the live status code.
  2. Check Response Headers — Look at Cache-Control, ETag, and Last-Modified. Make sure 404 responses are not cached long-term.
  3. Test A Direct Fetch — Use curl or another HTTP client to confirm what the server returns without browser caching.
  4. Audit Service Worker Caches — Clear caches, bump the worker version, then confirm activation on reload.

If the only issue is a plain missing page, the fix is still the same: restore the resource or point users to the new location. General 404 repair guides focus on redirects, file paths, and broken links, which still apply when caching is part of the story. 404 Error Causes And Fixes.

Final Check Before You Call It Done

Open DevTools, reload, and verify the request no longer says “from disk cache” when you expect a network fetch. Then reload once more with normal caching turned back on. If the second load stays clean, you’ve fixed the loop that was replaying the bad response.