Fetch API Caching: A Complete Guide

Caching feature of browser's Fetch API is one of the most powerful — and most misunderstood — tools in web development. It gives you fine-grained control over how HTTP requests interact with the cache through a single cache option. Used correctly, it can dramatically speed up your app, reduce server load, and improve offline resilience. Used incorrectly, it can serve stale data, confuse users, and cause hard-to-debug issues.

Before diving into the options, it's worth understanding what "the cache" actually means here.

When your browser makes an HTTP request, it can store the response in a local cache (the HTTP cache, sometimes called the browser cache). On subsequent requests to the same URL, the browser can serve the response directly from this cache instead of going to the network — making the response near-instant and saving bandwidth.

Servers communicate caching rules via HTTP response headers like Cache-Control,ETag, Last-Modified etc. The cache option in fetch() lets you influence how the browser interacts with the HTTP cache alongside these server-defined rules.

fetch(url, {
  cache: 'default' | 'no-store' | 'reload' | 'no-cache' | 'force-cache' | 'only-if-cached'
})

Important: The cache option influences how the browser interacts with the HTTP cache, but it does not completely override HTTP caching rules or browser behavior. Cache-related response headers such as Cache-Control, ETag, and Last-Modified still play a major role in determining whether a response can be cached, reused, or revalidated.

1. default — Standard Browser Behavior

fetch('/api/data')
// equivalent to:
fetch('/api/data', { cache: 'default' })

This is the browser's natural caching behavior — the same as if you typed a URL into the address bar. The browser checks its cache:

• If a fresh cached response exists, it returns it immediately without contacting the server.
• If the cached response is stale, the browser sends a conditional request (with If-None-Match or If-Modified-Since headers) to check if the content has changed. If unchanged, the server returns 304 Not Modified and the browser uses the cached version. If changed, it returns the new response.
• If nothing is cached, it fetches from the network and stores the response.

Use default for any standard data fetch. It's the right choice for most API calls, static assets, and anything where the server is already configured with proper caching policies.

2. no-store — Never Cache, Ever

fetch('/api/live-prices', { cache: 'no-store' })

With cache: 'no-store', the browser completely bypasses the HTTP cache. It does not check the cache for an existing response, and it does not store the fetched response in the cache. Every request goes directly to the network, and nothing is saved locally. The response is used once and discarded from a caching perspective.

It is useful when you always need a fresh response from the server and never want the data cached locally. Common use cases include real-time data such as stock prices, live scores, sensor readings, or auction bids; sensitive information like banking transactions, medical records; and scenarios where you need to guarantee that you are seeing the latest server response instead of a cached one.

3. reload — Fresh From Network, But Save It

fetch('/api/config', { cache: 'reload' })

The browser skips the cache on the way in (always fetches from the network, as if nothing were cached), but saves the new response to the cache on the way out. Think of it as a "force refresh" — you bypass any existing cached version, but the result is still stored for future use.

Unlike no-cache, reload is intended to bypass cache revalidation logic and fetch a fresh response from the network, updating the cached entry if the response is cacheable.

Use it when you want to bypass the existing cache for a request but still store the fresh response for future use. Common scenarios include after a user explicitly requests a refresh through a reload button, sync action, or pull-to-refresh gesture; after a form submission that updates server-side data and requires the latest state to be fetched; and during app initialization when you want to replace potentially stale cached data with a fresh response while keeping the cache populated for later requests.

4. no-cache — Always Check With the Server

fetch('/api/user/settings', { cache: 'no-cache' })

Despite the name, no-cache does use the cache — it just always validates first. The browser sends the request to the server with conditional headers (If-None-Match or If-Modified-Since), asking: "Has this changed since I last cached it?"

• If the content hasn't changed, the server responds with 304 Not Modified and the browser uses the cached version. This is fast and bandwidth-efficient.
• If the content has changed, the server sends the full new response, which the browser stores and returns.

cache: 'no-cache' works well for data that may change unpredictably but does not require constant real-time updates, such as user settings, feature flags, or notifications. It is also useful for authenticated or user-specific data where freshness matters, but you still want to reduce unnecessary bandwidth usage. In general, use it when you want the browser to verify cached data with the server before using it instead of blindly trusting the local cache.

5. force-cache — Use Cache, No Matter What

fetch('/api/countries', { cache: 'force-cache' })

The browser strongly prefers a cached response if one exists, including stale cached entries, without first revalidating with the server. A cached response from last week? Good enough. Only if there's no cached response at all does it go to the network (and then stores the result).

It is useful for data that rarely changes, such as country lists, currency codes, timezone data, or other static configuration values. It also works well in performance-critical situations where fast responses are more important than absolute freshness. Additionally, it can help reduce server load when the underlying data is known to remain stable for long periods.

6. only-if-cached — Cache or Bust

fetch('/data/cached-report', {
  cache: 'only-if-cached',
  mode: 'same-origin' // Required!
})

The browser never makes a network request. Instead, it only checks the HTTP cache. If a matching cached response exists — whether fresh or stale — it is returned immediately. If no cached response is found, the fetch rejects with a network error instead of falling back to the network. In other words, only-if-cached means “use the cache exclusively, or return an error.”

It's useful in offline-first applications where you want to display cached data when available and avoid accidental network requests. It is also commonly used in service workers and advanced caching strategies to check whether a resource already exists offline. Additionally, it can be helpful for testing whether a resource is present in the cache without triggering a network fetch.

Note: This must be used with mode: 'same-origin'. Cross-origin requests with only-if-cached will fail regardless.
Note: only-if-cached only works if the response was previously stored in the browser's HTTP cache. Responses marked with headers like Cache-Control: no-store are never cached, so they cannot be retrieved with only-if-cached.

Example:

// Offline-first article reader
async function loadArticle(articleId) {
  try {
    // Try to get from cache first — don't use network
    const response = await fetch(`/api/articles/${articleId}`, {
      cache: 'only-if-cached',
      mode: 'same-origin'
    });

    const article = await response.json();
    renderArticle(article);
    showOfflineBadge(); // Let user know this might not be latest

  } catch (err) {
    // Not in cache — show appropriate message
    if (!navigator.onLine) {
      showOfflineError('This article isn\'t available offline.');
    } else {
      // Online but not cached — fetch normally
      const response = await fetch(`/api/articles/${articleId}`);
      const article = await response.json();
      renderArticle(article);
    }
  }
}