Intent to Ship: deprecate BackgroundFetch

[Chromestatus]

Contact emails

yyana...@google.com

Explainer

No information provided

Specification

https://wicg.github.io/background-fetch

Summary

Deprecates the Background Fetch API, which allows web applications to download large files in the background, even if the user navigates away from the page or closes the browser. Despite being available in Chrome since version 74, the Background Fetch API has not seen wide adoption by the developer community, with usage remaining consistently low, at less than 0.00002% of page loads as of November 2025. Given the low adoption rate and the significant engineering effort required to maintain the API and address ongoing security issues, it is being deprecated. Developers are encouraged to explore alternative solutions for managing large file downloads.

Blink component

Blink>ServiceWorker

Web Feature ID

background-fetch

Motivation

The Background Fetch API has been available in Chrome since version 74. However, it has not seen wide adoption. Usage metrics show that the feature is used in less than 0.00002% of page loads as of November 2025. Given the low usage, the ongoing engineering effort to maintain the Background Fetch API and address security issues is no longer justifiable. For developers who need to provide users with the ability to download large files, there are several alternatives: - For simple file downloads, developers can provide a standard download link. - For more advanced use cases, such as providing offline access to large files, developers can use the Fetch API within a Service Worker to download and cache the necessary resources. This approach provides developers with greater control over the user experience.

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The interoperability risk of removing the Background Fetch API is low. The API has not been implemented by Firefox or Safari, and there have been no signals from either to indicate that they intend to do so. As a result, removing this API from Chrome will not cause interoperability issues, as it is not a feature that is part of the interoperable web platform. The compatibility risk is also minimal. Usage of the Background Fetch API has remained consistently low, at less than 0.00002% of page loads as of November 2025. Because of this extremely low usage, the number of websites that will be affected by this removal is very small.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/30)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/149)

Web developers: No signals

Other signals: TAG: https://github.com/w3ctag/design-reviews/issues/279

Ergonomics

The Background Fetch API is tightly coupled with the Service Worker API. It is accessed through the backgroundFetch property of a ServiceWorkerRegistration object. Developers using this API would also likely use the Fetch API to create the Request objects for the download and the Cache API to store the downloaded responses. The API is designed to be asynchronous and to operate in the background. The main fetch() method returns a Promise, and the download process is managed by the browser, off the main thread. This design avoids blocking the main thread and is intended to improve performance and battery life for large downloads compared to keeping a service worker alive for a long-running fetch. Therefore, the API's usage does not inherently pose a performance risk that would make it difficult for Chrome to maintain good performance. The deprecation is due to low adoption and high maintenance cost, not because of ergonomic or performance issues in its design.

Activation

This change is a deprecation and removal of an existing API. The primary risk is the impact on developers who are currently using the Background Fetch API. However, the "activation" risk for this removal is minimal. The API has seen extremely low adoption since its introduction in Chrome 74, with usage below 0.00002% of page loads. This indicates that very few developers will be required to take action.

Security

The removal of the Background Fetch API reduces the overall attack surface of the browser and mitigates existing security issues associated with maintaining the feature.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

No information provided

Finch feature name

BackgroundFetch

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/460293588

Estimated milestones

Shipping on desktop	146
Shipping on Android	146
Shipping on WebView	146

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5074579353632768?gate=6606728540061696

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

What would breakage look like? I agree that usage is very low, but would you expect users of those rare sites to be aware of breakage? Or would it just prevent those sites from optimizing some flows?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com.

[Yoshisato Yanagisawa]

Since it is implemented with a Runtime feature flag, it should be seen as the ServiceWorker registration does not have the backgroundFetch field.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/background_fetch/service_worker_registration_background_fetch.idl;l=12;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77

Then, they should be aware of the case as the lack of the field.

2025年11月25日(火) 17:46 Yoav Weiss (@Shopify) <yoav...@chromium.org>:

[Thomas Steiner]

I have recently suggested sites use this API to download large AI models in the background as a progressive enhancement (so no breakage).

> For more advanced use cases, such as providing offline access to large files, developers can use the Fetch API within a Service Worker to download and cache the necessary resources.

It sounds like this is only possible until the UA kills the service worker, as it's not meant to be kept alive indefinitely, which would be a requirement for the use case described above. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Bcs0k2mxNHSZse%2BGdB8Z9Ei8%2BADkaLh-fxRe%3DoJqWLMw%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Spain, S.L.U.

Torre Picasso, Pl. Pablo Ruiz Picasso, 1, Tetuán, 28020 Madrid, Spain

CIF: B63272603

Inscrita en el Registro Mercantil de Madrid, sección 8, Hoja M­-435397 Tomo 24227 Folio 25

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.8 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

[Yoav Weiss (@Shopify)]

LGTM1

[Yoshisato Yanagisawa]

Hi Thomas,

Thank you for raising the use case regarding large AI model downloads and for pointing out the limitations of the Service Worker alternative. I agree that the ability to continue large downloads independent of the Service Worker's lifecycle is a key feature that Background Fetch offered.

However, after reviewing the usage metrics at https://chromestatus.com/metrics/feature/timeline/popularity/2550, we see very little change in overall adoption. Given this persistently low usage and the significant engineering effort required to maintain the API and address security concerns, we still feel strongly that deprecating Background Fetch is the correct path forward for Chrome.

Thank you again,

Yoshisato

2025年11月25日(火) 18:44 Yoav Weiss (@Shopify) <yoav...@chromium.org>:

[Mike Taylor]

Is this a request to deprecate for some number of milestones then remove (if so, what is the proposed plan?), or just a straight removal? Could you clarify? Thanks.

[Alex Russell]

This capability was developed in conjunction with media app developers. Have we heard from them? I'd also like to understand Jake Archibald's perspective.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

I'm a bit worried that the UseCounter may be misleading. While the UseCounter is low, it's still about 2x the level we call "trivial". We've seen situations in the past where rare activities (eg. some specific aspect of payments or account creation) were nonetheless really critical to some sites. Our content does a pretty good job of explaining why this API is sometimes essential, and coincidentally just yesterday I had recommended it to someone who was complaining that the web lacked this important facility. Is Thomas correct that really you can't rely on being able to just use a SW for long-running background download tasks? Our compat principles cover this sort of case pretty clearly IMHO:

A change which can be trivially accounted for (such as by replacing a webkit-prefixed API name with the non-prefixed version) is generally considered to be lower risk than one which requires more effort.  At the extreme end, a breaking change which takes away a capability (no matter how minor) which cannot be achieved by any other mechanism is generally considered high risk.

To move forward I guess what I'd like to see is some feedback from developers who are actually using the Background Fetch API. Do they agree it's unimportant and they can replace it with something else? Or do some of them at least feel like the capabilities of their application would be significantly reduced without this API? Can we look at the HTTP Archive hit (which only tracks API use on page load by the way), some UKM UseCounters, and/or the ~100 hits in GitHub to see if we can get any sentiment from web developers?

Thanks,

   Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0787a736-c17f-497b-979c-eb50355086b9n%40chromium.org.