Background Sync: Browser Support, Features, Limitations

What is Background Sync?

Background Sync is a JavaScript API that lets a web app register a task in a service worker so the browser runs it later when the device has stable network. The Web Platform Incubator Community Group at the W3C edits the spec, and the SyncManager interface attached to ServiceWorkerRegistration is the entry point.

Which browsers does Background Sync support?

Chromium-based desktop and Android browsers ship Background Sync by default, while Firefox and every Safari version leave it out, putting global support at about 76% of users.

What are the use cases of Background Sync?

Background Sync fits any flow where the user takes an action that has to reach the server, but the network is not guaranteed at that moment. Production PWAs use it to make offline writes feel reliable.

• Send chat messages and emails: A mail or chat PWA stores the outgoing message in IndexedDB and registers a sync tag. The service worker fires the actual POST when the network returns, even if the user has closed the tab.
• Submit form data: A form-heavy app queues the request body when fetch fails. The sync event handler replays the queued request, so users do not have to retry by hand after a tunnel or elevator drop.
• Upload photos and small files: A social or note-taking app queues a single photo upload. The browser retries with exponential backoff until the file lands on the server, then clears the tag.
• Update settings and preferences: A dashboard saves a preference change locally and registers a sync. The change reaches the account server even if the user toggles airplane mode while saving.
• Sync notes and offline edits: An editor like Google Docs uses the sync queue to push the diff once the laptop reconnects to wifi, instead of relying on a fragile setInterval poll.
• Workbox queue plugin: Workbox ships a BackgroundSyncPlugin that wraps Background Sync around any failed POST. PWAs using Workbox get a drop-in offline retry queue without writing the sync event handler from scratch.

What are the known limitations of Background Sync?

Background Sync is a small, sharply scoped API. Most of the painful edge cases come from cross-browser gaps, the tight time budget, and the way the browser decides when to fire the sync event.

• No Firefox or Safari support: Firefox, Safari on macOS, Safari on iPadOS, and Safari on iOS all lack SyncManager. Sites that need offline replay on those browsers must keep a queue in IndexedDB and replay on the next page load.
• Secure context only: Background Sync requires HTTPS, like every other service worker API. The localhost origin is treated as secure for development, but plain http origins get a SyncManager that throws on register.
• Short execution window: The browser keeps the service worker alive for a few minutes per sync attempt, then terminates it. Long uploads or downloads should use the Background Fetch API, which is built for transfers that may take an hour.
• lastChance flag: The SyncEvent has a lastChance boolean that is true on the final retry. After the last chance, the tag is dropped and the work is lost unless the page registers it again on next visit.
• No exact retry schedule: The browser owns the retry timing, with exponential backoff and a battery and network heuristic. Pages cannot pin a retry to a wall-clock time, which makes Background Sync unfit for time-critical flows.
• Tag deduplication: Calling register twice with the same tag is a no-op once the first registration is pending. Pages that need parallel work should generate unique tags or store the payload in IndexedDB and key off that.
• No fine-grained progress events: The sync event resolves a single Promise with waitUntil. There is no built-in stream of progress, so per-item progress UI has to bridge through postMessage from the service worker.
• WebView and iOS PWAs lose the queue: Android WebView and PWAs installed from Safari on iOS do not run sync events. An app that wraps a web frontend in either container needs a native fallback queue.

In my experience, the trickiest failure is silent data loss on iOS. A team I worked with shipped a Background Sync queue for a field-service PWA and assumed iPad users were covered, since the same code worked in Chrome on Android. iPad users lost any write made while offline, because Safari never fires the sync event. The fix was a manual replay loop on the next visibilitychange event, gated by feature detection of registration.sync.

Citations

All Background Sync version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - Background Synchronization API: developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API
• MDN Web Docs - SyncManager interface: developer.mozilla.org/en-US/docs/Web/API/SyncManager
• MDN Web Docs - Web Periodic Background Synchronization API: developer.mozilla.org/en-US/docs/Web/API/Web_Periodic_Background_Synchronization_API
• WICG - Web Background Synchronization spec: wicg.github.io/background-sync/spec
• WICG - Background Sync explainer: github.com/WICG/background-sync/blob/main/explainers/sync-explainer.md
• WICG - Periodic Background Sync explainer: wicg.github.io/periodic-background-sync
• Chrome for Developers - Introducing Background Sync: developer.chrome.com/blog/background-sync
• web.dev - Periodic Background Sync pattern: web.dev/patterns/web-apps/periodic-background-sync
• Microsoft Learn - Synchronize and update a PWA in the background: learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps/how-to/background-syncs
• Workbox - background-sync module: developer.chrome.com/docs/workbox/modules/workbox-background-sync
• Chrome Platform Status - Background Sync feature: chromestatus.com/feature/6170807885627392
• WebKit - Standards Positions: webkit.org/standards-positions