ERR_CACHE_MISS: What It Means And How To Fix It

ERR_CACHE_MISS is one of the more misunderstood errors in Chrome. Almost every guide to it tells you to clear your browser cache, and for the most common version of this problem, clearing your cache does nothing at all.

The error is not a sign that something is broken. Most of the time it is a safety feature working exactly as designed, and the message you are seeing is the browser refusing to do something risky on your behalf. This guide explains what the error genuinely means, the one cause behind most of the reports, the handful of fixes that actually apply to a visitor, and the single change a site owner needs to make to stop it happening to anyone.

What ERR_CACHE_MISS Actually Means

ERR_CACHE_MISS is a network error from Chromium, the open-source engine behind Chrome, Edge, Brave, Opera and Vivaldi. Chromium keeps a numbered list of every error its network stack can produce, and this one is number -400. The Chromium source defines it in a single line:

// The cache does not have the requested entry.
NET_ERROR(CACHE_MISS, -400)

That definition is worth reading twice, because it settles a lot of bad advice. It does not say the cache is damaged, full, or out of date. It says something asked the cache for a specific entry, and that entry was not there.

This matters because Chromium has separate error codes for the problems people assume ERR_CACHE_MISS represents. A corrupted cache entry produces -401 or -408. A cache that cannot be written to produces -402. If your cache really were broken, you would be looking at a different number. Error -400 is not a fault report. It is a lookup that came back empty.

Why Something Would Ask For A Cache-Only Load

The next question is why the browser would insist on the cache in the first place, rather than simply fetching the page again from the network. The answer is a flag in Chromium called LOAD_ONLY_FROM_CACHE, described in the load flags list as a navigation that will fail if it cannot serve the resource from a local store.

So the whole mechanism reduces to one sentence: something requested a cache-only load, and the entry was not there. Every genuine cause of this error is a variation on who set that flag and why the entry went missing.

The Real Cause: Back, Reload And Forms

In the large majority of real cases, the answer is a form submission. Here is the sequence, and it is worth following closely because everything else in this article follows from it.

1. You fill in a form and submit it. Your browser sends a POST request, carrying your data in the request body, and the site responds with a page.
2. That page in your history is not identified by its address alone. It is tied to the data you submitted. The address on its own is not enough to rebuild it.
3. You press Back, or Reload, to return to it.
4. The browser will not silently send your form data a second time. POST is defined as neither safe nor idempotent, which is the specification's way of saying that repeating one may cause the same thing to happen twice, such as placing the same order again. So it attempts a cache-only load instead.
5. The page is not in the cache. POST responses are only stored under narrow conditions, and pages behind a login or a checkout routinely instruct the browser never to store them at all. The lookup returns nothing.
6. Chrome reports that as ERR_CACHE_MISS, usually behind a "Confirm Form Resubmission" screen.

Read that back and the important point stands out. The error is the safety feature working. Chrome has spotted that recreating the page would mean sending your payment, your signup, or your order a second time, and it has stopped and asked instead. If it silently reloaded, people would be charged twice.

Two Things You Will Read Elsewhere That Are Wrong

The first is that this happens when you press Back or Forward "too often, or too quickly". Speed has nothing to do with it. There is no race and no timing window. Either the history entry needs form data that is no longer held, or it does not. The behaviour is completely deterministic, and clicking more slowly will never change it.

The second is that the fix is to turn off your browser's cache. Some guides list this as a step. It is precisely backwards: as the next section explains, disabling the cache is one of the ways to cause this error.

How To Fix It As A Visitor

If you have hit this error on someone else's site, the honest answer is that there is not much to repair, because in the usual case nothing is broken. These are the steps that genuinely apply, in the order worth trying them.

1. Go Forwards, Not Backwards

Do not press Reload. Reloading asks for exactly the thing that is missing, so it will fail the same way every time. Instead, navigate to the page you want directly: click through from a link, use a bookmark, or type the address. That turns the request into an ordinary GET, which needs no form data and will simply work.

If you were part-way through a checkout or a signup, check your email or your account area before starting again. The action very often completed successfully, and only the display of the confirmation page failed.

2. Check Whether DevTools Is Disabling Your Cache

This is the cause people miss, and it produces the most confusing version of the problem. Chrome's developer tools have a Disable cache checkbox on the Network panel. When it is ticked, Chrome bypasses the cache entirely, so any cache-only load has nothing to find.

The setting only applies while DevTools is open, which is why it creates such a strange pattern: the site breaks for you and nobody else, and only sometimes. If you ever open DevTools, open the Network panel and confirm that box is clear.

3. Rule Out Extensions With An Incognito Window

Extensions that intercept requests, particularly ad blockers, privacy tools and anything that auto-refreshes tabs, can block or rewrite a request in a way that leaves the cache without the entry the browser expects.

Rather than disabling extensions one at a time, open an Incognito window, where most extensions are off by default, and try the page there. If it works in Incognito, an extension is responsible, and you can then re-enable them in batches to find which one.

4. Clear Your Cache, With Realistic Expectations

Clearing your browsing data is the advice attached to almost every article on this error, and it is worth being straight about it: for the form resubmission case it will not help, because the problem is a missing entry rather than a bad one, and clearing the cache removes entries.

It is still worth doing if the error appears on ordinary pages with no form involved, since that pattern points at genuine local cache trouble, which does happen occasionally. Clear cached images and files in Chrome's settings, then reload.

5. Update Chrome

Worth thirty seconds. Go to the menu, then Help, then About Google Chrome, and let any pending update install. Browser bugs in this area are uncommon but not unheard of, and running a current version rules one out.

What is not worth your time is resetting your network settings or flushing your DNS. Those steps appear on a lot of lists, but there is no causal path from your network configuration to a cache entry lookup. Treat them as a last resort, and expect nothing.

How To Fix It As A Site Owner

If your visitors are hitting this error, no amount of advice about clearing their cache will help, because the cause is on your side. The fix is a pattern called Post/Redirect/Get, and it has been the correct answer to this problem for more than twenty years.

The Pattern

The rule is simple: never render a page in response to a POST. Do the work, then redirect the browser to a normal address, and let it fetch the result with a GET.

Without PRG (causes the error)
  POST /checkout  ->  200 OK, order confirmation HTML
                      Back or Reload needs the POST body -> ERR_CACHE_MISS

With PRG (no error possible)
  POST /checkout  ->  303 See Other
                      Location: /orders/12345/confirmation
  GET  /orders/12345/confirmation  ->  200 OK, order confirmation HTML
                      Back or Reload just repeats a harmless GET

After the redirect, the page sitting in the visitor's history is a plain GET at a real address. There is no form data attached to it, so nothing can go missing, so there is no cache-only load and no error. As a bonus, the confirmation page becomes something the visitor can bookmark, refresh and share, which the original never was.

Use 303, Not 302 Or 307

The status code matters here, and picking the wrong one reintroduces the problem.

The MDN documentation for 303 See Other is explicit that the method used to retrieve the redirected resource is always GET, which is exactly the guarantee this pattern depends on.

In WordPress

WordPress ships the helper you need. After handling a form submission, redirect rather than continuing to render:

// Handle the submission, then get out of the POST
if ( 'POST' === $_SERVER['REQUEST_METHOD'] ) {
    $order_id = my_plugin_process_order( $_POST );

    wp_safe_redirect( home_url( "/orders/{$order_id}/confirmation" ), 303 );
    exit; // always exit after a redirect
}

Two details people get wrong. Pass 303 explicitly, because the default is 302. And always call exit immediately afterwards, or execution continues and the page renders anyway, which defeats the whole exercise.

What Post/Redirect/Get Does Not Solve

Worth knowing so you do not assume you are covered. PRG stops the duplicate submission that comes from Back and Reload after a request finishes. It does nothing about a visitor who clicks Submit twice while the first request is still in flight, which is a common cause of duplicate orders on a slow connection. For that you need to disable the submit button on click, and ideally accept a one-time token with each submission so the server can reject the second attempt.

The Other Genuine Causes

Form resubmission accounts for most reports, but not all. Here is an honest split of the rest, because articles on this topic have a habit of implying that a hosting change will fix a browser-side problem.

Service Workers And Cache Storage

A service worker sits between your site and the network and can answer requests itself, usually from the Cache Storage API. If it is written to serve a file it expects to be cached, and that file is not there because the install step failed part way or a cleanup routine deleted a cache still in use, the request fails.

This is a bug in the site's own code rather than in the browser. Diagnose it in DevTools under Application, where both the Service Workers and Cache Storage panels are listed. Unregistering the worker and hard-reloading confirms it quickly.

Caching Headers

Two values in the Cache-Control header get mixed up constantly, and the difference is the whole subject:

• no-cache does not mean "do not cache". It means store the response, but check with the server before reusing it.
• no-store means never write it down at all.

Sending no-store on a page and then expecting Back to restore it is a contradiction: you asked for it not to be kept, and it was not kept. On genuinely sensitive pages that is the right call, and the answer is Post/Redirect/Get rather than weakening the header. The storage rules are set out in RFC 9111, and web.dev's guide to the HTTP cache is a readable summary.

WordPress Caching Plugins

Where WordPress is genuinely implicated, it is usually a caching plugin treating a POST like an ordinary page view, or interfering with admin-ajax.php. Every serious caching plugin excludes POST requests, checkout and cart pages and logged-in sessions by default, so problems here almost always come from a custom exclusion rule that has been edited. Check those rules first, and see the official WordPress optimization documentation for how the layers are meant to fit together. Our guide to WordPress maintenance covers keeping those settings in order.

What Other Browsers Show Instead

ERR_CACHE_MISS is Chromium wording, so you will only ever see that exact string in Chrome and its relatives. The underlying situation is universal, though: no browser will quietly re-send your form data. They simply describe it differently, and only Chrome makes it look like a failure.

This is a useful diagnostic. If a page misbehaves in Chrome and you want to know whether you are looking at this problem or something else, open it in Firefox. "Document Expired" confirms it immediately.

Why Back Sometimes Just Works

If pressing Back is such a problem, why is it usually instant and flawless? Because a second, separate mechanism handles most of those navigations: the back/forward cache, or bfcache.

The bfcache is not the HTTP cache. Rather than storing a copy of a file, it freezes the entire page in memory, so going back restores it in the state you left it. That is why Back is normally immediate and keeps your scroll position. As web.dev's bfcache guide explains, pages are excluded from it under various conditions, including Cache-Control: no-store and the use of an unload event handler.

The two caches are easy to confuse and it is worth keeping them apart: bfcache decides whether Back is instant, while the HTTP cache decides whether a cache-only load can be satisfied. ERR_CACHE_MISS comes from the second one.

When This Is Actually Worth Worrying About

A visitor who sees this once, after pressing Back on a form, has encountered a browser safety feature and needs no help beyond navigating forwards.

It becomes a real problem when it is repeatable: when a checkout, a signup, or a contact form produces it for a meaningful share of visitors. At that point it is costing conversions, and no amount of visitor-side troubleshooting will address it. The fix is Post/Redirect/Get, applied to whichever forms are involved, and it is usually a small change.

If the error appears alongside other symptoms, such as pages timing out or intermittent failures on ordinary GET requests, the cache is probably not the story. Our guides to connection timed out errors and DNS server not responding cover those paths instead.