This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

The respondWith() method of FetchEvent prevents the browser's default fetch handling, and allows you to provide a promise for a Response yourself.

In most cases you can provide any response that the receiver understands. For example, if an <img> initiates the request, the response body needs to be image data. For security reasons, there are a few global rules:

Specifying the final URL of a resource

From Firefox 59 onwards, when a service worker provides a Response to FetchEvent.respondWith(), the Response.url value will be propagated to the intercepted network request as the final resolved URL.  If the Response.url value is the empty string, then the FetchEvent.request.url is used as the final URL.

In the past the FetchEvent.request.url was used as the final URL in all cases.  The provided Response.url was effectively ignored.

This means, for example, if a service worker intercepts a stylesheet or worker script, then the provided Response.url will be used to resolve any relative @import or importScripts() subresource loads (bug 1222008).

For most types of network request this change has no impact because you can't observe the final URL.  There are a few, though, where it does matter:

  • If a fetch() is intercepted, then you can observe the final URL on the result's Response.url.
  • If a worker script is intercepted, then the final URL is used to set self.location and used as the base URL for relative URLs in the worker script.
  • If a stylesheet is intercepted, then the final URL is used as the base URL for resolving relative @import loads.

Note that navigation requests for Windows and iframes do NOT use the final URL.  The way the HTML specification handles redirects for navigations ends up using the request URL for the resulting Window.location.  This means sites can still provide an "alternate" view of a web page when offline without changing the user-visible URL.

Syntax

fetchEvent.respondWith(
  // Promise that resolves to a Response.
​)

Parameters

A Promise for a Response.

Return value

Void.

Exceptions

Exception Notes
NetworkError A network error is triggered on certain combinations of FetchEvent.request.mode and Response.type  values, as hinted at in the "global rules" listed above.

Examples

This fetch event tries to return a response from the cache API, falling back to the network otherwise.

addEventListener('fetch', event => {
  // Prevent the default, and handle the request ourselves.
  event.respondWith(async function() {
    // Try to get the response from a cache.
    const cachedResponse = await caches.match(event.request);
    // Return it if we found one.
    if (cachedResponse) return cachedResponse;
    // If we didn't find a match in the cache, use the network.
    return fetch(event.request);
  }());
});

Specifications

Specification Status Comment
Service Workers
The definition of 'respondWith()' in that specification.
Working Draft Initial definition.

Browser compatibility

Update compatibility data on GitHub
DesktopMobile
ChromeEdgeFirefoxInternet ExplorerOperaSafariAndroid webviewChrome for AndroidEdge MobileFirefox for AndroidOpera for AndroidSafari on iOSSamsung Internet
Basic support
Experimental
Chrome Full support 42
Notes
Full support 42
Notes
Notes NetworkError thrown if request mode is same-origin and response type is cors (see bug 1222008). This is being worked on — see https://www.chromestatus.com/feature/5694278818856960.
Edge ? Firefox Full support 59
Notes
Full support 59
Notes
Notes NetworkError thrown if request mode is same-origin and response type is cors (see bug 1222008).
Full support 44
Notes
Notes Service workers (and Push) have been disabled in the Firefox 45 and 52 Extended Support Releases (ESR.)
IE No support NoOpera Full support 29Safari No support NoWebView Android Full support 42
Notes
Full support 42
Notes
Notes NetworkError thrown if request mode is same-origin and response type is cors (see bug 1222008). This is being worked on — see https://www.chromestatus.com/feature/5694278818856960.
Chrome Android Full support 42
Notes
Full support 42
Notes
Notes NetworkError thrown if request mode is same-origin and response type is cors (see bug 1222008). This is being worked on — see https://www.chromestatus.com/feature/5694278818856960.
Edge Mobile ? Firefox Android ? Opera Android Full support 29Safari iOS ? Samsung Internet Android Full support 4.0
Change in behavior when specifying the final URL of a resource.
Experimental
Chrome No support NoEdge ? Firefox Full support 59IE No support NoOpera ? Safari No support NoWebView Android No support NoChrome Android No support NoEdge Mobile ? Firefox Android ? Opera Android ? Safari iOS No support NoSamsung Internet Android No support No

Legend

Full support  
Full support
No support  
No support
Compatibility unknown  
Compatibility unknown
Experimental. Expect behavior to change in the future.
Experimental. Expect behavior to change in the future.
See implementation notes.
See implementation notes.

See also

Document Tags and Contributors

Last updated by: BrantNielsen,