What Background sync is (and what it’s not) .
This guide reflects how current Chrome manages the Background Sync permission and related “background” behaviors on desktop and mobile.
Background sync in Chrome is a web capability that allows a site’s service worker to finish or retry a network operation later—typically when your device regains connectivity. In plain terms: if a site tries to send something (a message, a form submission, an upload) and you go offline, Chrome can let that site queue the work and retry in the background instead of failing and forcing you to redo it.
The important part is that Background sync is controlled through Chrome’s site permissions system. Chrome’s own documentation and developer guidance describe Background Sync as a way to “defer actions until the user has stable connectivity,” so the task completes reliably rather than failing at the worst moment. :contentReference[oaicite:2]{index=2} The permission you toggle in Settings is what enables or disables that behavior.
What it is not: it is not the same thing as Chrome account sync (bookmarks/passwords syncing to Google), and it’s not the same thing as the desktop setting “Continue running background apps when Google Chrome is closed.” Those are separate features with separate privacy and performance tradeoffs. This page focuses on the site permission called Background sync.
Key terms (quick definitions) .
- Service worker: A background script that can handle offline caching, push notifications, and background tasks for a website.
- Background Sync API: A web API that lets a site’s service worker schedule a one-off sync when the network is available again. :contentReference[oaicite:3]{index=3}
- Periodic Background Sync: A related API that can sync at intervals (where supported/allowed), typically with tighter restrictions and user-agent controls. :contentReference[oaicite:4]{index=4}
- Site permission: A per-site allow/block rule in Chrome’s Site settings (camera, notifications, background sync, etc.). :contentReference[oaicite:5]{index=5}
Related: For a broader privacy baseline first, start with Chrome Privacy Settings and then drill into Chrome Site Permissions.
Why people search for “background sync” (real-world intent) .
In analytics, “background sync” tends to show up in three user stories:
- Privacy concern: “Why is this site doing things when I’m not on it?” Users want fewer background requests and less tracking.
- Battery/data concern (mobile): Users see unexplained data usage and want to reduce it.
- Troubleshooting: A web app misses messages, fails to send uploads, or acts unreliable on bad Wi-Fi and the user wants it stable again.
The settings you choose should match your actual goal. If you block Background sync globally, some web apps become “less smart” about offline/retry behavior. That can be fine! But it’s worth understanding what breaks, how to allow exceptions safely, and what else you should lock down (like third-party cookies and noisy permissions).
Before you start (fast checks) .
These checks prevent wasted time and help you diagnose whether Background sync is the real cause. Chrome UI varies slightly by platform, and some settings are hidden or enforced on managed devices.
- Check your Chrome version: Go to chrome://settings/help (desktop) and confirm you’re on a recent stable build. Chrome 145 is the current stable major version in late February 2026. :contentReference[oaicite:6]{index=6}
- Confirm you mean “Background sync,” not “Chrome Sync”: If you’re trying to stop bookmarks/passwords syncing, you want account sync controls (different setting and different risk model).
- Check if the device is managed: On work/school devices, policies can lock permissions. You can usually tell by “Managed by your organization” in Settings, or by checking chrome://policy. :contentReference[oaicite:7]{index=7}
- Decide your strategy up front: Most users do best with Block globally + allow per site for only trusted web apps.
Related: If Chrome feels slow while troubleshooting, use the performance cluster: Performance Optimization, plus these focused guides: Limit Background Tabs and Background Process Control.
Step-by-step: change Background sync (desktop + mobile) .
Chrome manages Background sync in Site settings alongside permissions like notifications, location, camera, and microphone. Google’s support steps for changing site permissions start from Settings → Privacy and security → Site settings on desktop. :contentReference[oaicite:8]{index=8} From there, you find Background sync (sometimes under “Additional permissions”).
Desktop (Windows, macOS, Linux, ChromeOS) .
- 1 Open Chrome and click ⋮ (three dots) → Settings.
- 2 Go to Privacy and security → Site settings. :contentReference[oaicite:9]{index=9}
- 3 Scroll to Additional permissions (if shown), then open Background sync.
- 4 Choose your default:
- Block to prevent sites from scheduling background retry work.
- Allow (or “Sites can…” depending on UI) if you want maximum reliability for web apps.
- 5 For exceptions, use the Allowed / Blocked lists on that page and add specific sites.
What “success” looks like: After setting a global default, a site you visit should inherit that rule. If you add an exception, it should appear in the allow/block list, and the site’s permission panel should show the same choice.
Android (Chrome on Android) .
On Android, Chrome exposes site permission controls from the address bar’s site info panel and from Settings. Google’s official steps for changing permissions on Android start from visiting a site, opening site info, and adjusting permissions. :contentReference[oaicite:10]{index=10}
- 1 Open Chrome on Android and go to the site you care about.
- 2 Tap the site info icon (left of the address bar) → Permissions. :contentReference[oaicite:11]{index=11}
- 3 Look for Background sync (if listed) and set it to Allow or Block.
- 4 If you don’t see it, use Chrome Settings → Site settings and look for it under additional permissions (device/UI dependent).
Android reality check: Mobile UI can hide some permissions depending on device vendor and Chrome build. If you can’t find Background sync at all, you can still apply a practical equivalent approach: reset the site’s permissions, block high-risk permissions (notifications, pop-ups), and restrict background data for Chrome at the Android OS level.
iPhone / iPad (Chrome on iOS) .
Chrome on iOS uses Apple’s WebKit under the hood and permission surfaces differ from Android and desktop. In practice, iOS users get the best results by controlling the site’s most relevant permissions (notifications, camera/mic, location where applicable) and using OS-level background refresh and data controls. If you’re specifically seeing “sync” behavior on iPhone, verify whether it’s account sync (Google account) vs site background tasks.
Tip for iOS users: If the problem you’re trying to solve is “this site keeps doing things,” start with Notifications and Website Data (clear data for that site), then revisit whether Background sync is even the culprit.
Common variations by platform .
- Windows / ChromeOS: Background sync is usually under Site settings; “Continue running background apps…” is under System settings (separate feature).
- macOS: Same as Windows, but background process behavior can feel different due to macOS energy management.
- Android: Site info → Permissions is often the fastest. :contentReference[oaicite:12]{index=12}
- iPhone: Don’t expect feature parity; use OS-level controls for background behavior.
Advanced: behavior, edge cases, enterprise notes .
This section is for readers who want to understand what the toggle changes in practice, how it interacts with other Chrome “background” settings, and how to reason about risk in business environments.
What the Background Sync permission actually gates .
The Background Sync API is designed to let web apps defer a sync task until connectivity returns. MDN describes it as deferring server synchronization work to a service worker “at a later time” if the device is offline. :contentReference[oaicite:13]{index=13} Chrome’s own developer guidance describes it as deferring actions until the user has stable connectivity. :contentReference[oaicite:14]{index=14} And Chromium engineers have explicitly clarified that the “content setting” (the permission you toggle) enables you to disable this behavior globally or per website. :contentReference[oaicite:15]{index=15}
In practice, that means:
- Allow: A site can register sync events so Chrome can retry later (useful for offline-first web apps).
- Block: The site loses that mechanism; it must fall back to retry-on-next-open or fail-and-prompt patterns.
Background sync vs “Continue running background apps…” .
Chrome’s desktop setting Continue running background apps when Google Chrome is closed is separate. It controls whether Chrome keeps certain background processes alive after you close the last window. Security baselines (like CIS guidance) and tech support guides often mention it because it affects performance and background resource usage. :contentReference[oaicite:16]{index=16}
If your concern is “Chrome is still running after I close it,” you may want to disable that System setting. If your concern is “a specific site keeps retrying requests in the background,” you want the Background sync permission. Many people mix these up because both include the word “background,” but they solve different problems.
Related: For a deep dive on background resource use, see Background App Performance Impact and Limit Background Tabs.
Periodic Background Sync and why it’s more sensitive .
Periodic Background Sync is the “sync at intervals” cousin of Background Sync. Chrome’s capability docs describe it as enabling web apps to periodically synchronize data in the background. :contentReference[oaicite:17]{index=17} MDN describes the Web Periodic Background Synchronization API similarly, focused on periodic tasks run in a service worker. :contentReference[oaicite:18]{index=18}
From a privacy perspective, periodic “phone home” behavior is more sensitive because it can create repeatable network patterns even when you’re not actively using the site. That’s why browsers and standards groups treat it carefully, with restrictions and permission models. If your background sync concern is tracking-related, periodic sync (where available) is exactly the kind of mechanism you’d want to be strict about.
Enterprise and managed-device considerations .
In managed environments, permissions can be enforced through policy. If Background sync is greyed out, blocked, or missing, you should first verify whether the browser is policy-controlled. Google’s admin guidance includes how policies apply across users/devices and how admins manage them, and Chrome provides a built-in policy viewer at chrome://policy. :contentReference[oaicite:19]{index=19}
Common alternatives users compare .
- Chrome built-in permissions vs privacy extensions (extensions can help, but add their own trust model and attack surface)
- Per-site allow lists vs global block (best practice: global block + allow only what you trust)
- Manual hardening vs enterprise policy management (policy is the only scalable approach in business fleets)
- Chrome password manager + sync vs dedicated password managers (separate topic, but frequently confused with “sync” terminology)
Related: If you’re evaluating security posture of extensions that run in the background, read Extension Background Script Security and the broader Chrome Extension Security hub.
Privacy & security notes (tracking + threat model) .
Background sync is not “evil,” but it is powerful. Any capability that allows a site to initiate requests outside your active browsing session can increase privacy exposure and expand the time window for abuse if a site is compromised or sold to a less trustworthy operator. That’s why it’s smart to treat it like notifications: allow it only on sites you recognize and benefit from.
Impact: Affects background request retries, offline-first behavior, and the potential for repeated “phone home” patterns.
To understand the “why” behind this risk classification, you need two facts:
- Background Sync is specifically designed to let a service worker retry synchronization later. :contentReference[oaicite:21]{index=21}
- Chrome exposes a content setting (permission) that can disable this behavior globally or per website. :contentReference[oaicite:22]{index=22}
When you allow a site, you are trusting it to behave reasonably with that capability. Most reputable web apps use it to improve reliability: “send this message when the train tunnel ends,” “upload the draft when Wi-Fi returns,” “sync tasks when the device is back online.” But a low-quality site can use the same plumbing to create a persistent background request pattern that you didn’t intend.
Recommended baseline settings .
- Option A (balanced): Default Allow, but block it on unknown sites and any site you don’t log into.
- Option B (maximum privacy): Default Block, then allow only a short list of trusted web apps (mail/chat/work tools).
- Option C (compatibility): Default Allow on personal devices; use strict per-site blocking only when you notice suspicious behavior.
Recommended settings by goal .
| Goal | Recommended setting | Tradeoff | Best for |
|---|---|---|---|
| Balanced | Allow globally, block per-site on low-trust domains | Requires occasional tuning | Most users |
| Maximum privacy | Block globally, allow only a short whitelist | Some web apps lose offline/retry convenience | Tracking-sensitive users |
| Compatibility | Allow globally, rely on other controls (cookies, site data) | More background request surface | Banking / enterprise / legacy web apps |
Related: For broader tracking reduction beyond Background sync, see Third-Party Cookies Settings, How to Stop Chrome Tracking, and Chrome Data Collection Settings.
Troubleshooting .
If you can’t find Background sync, the setting doesn’t stick, or a site still behaves oddly, work through these common causes. The goal is to isolate whether this is a permission problem, a policy problem, or a different “background” feature.
Related: For permission-related issues generally, use Chrome Site Permissions Settings and the privacy hub: Privacy Settings.
If you can’t find “Background sync” in Site settings .
First, use the Settings search box and type background or sync. Chrome sometimes groups lesser-used permissions under “Additional permissions.” If you still can’t find it:
- Confirm you’re on desktop: iOS may not expose the same permission UI as desktop/Android.
- Check if the browser is managed: Policies can hide or enforce settings. Use chrome://policy. :contentReference[oaicite:23]{index=23}
- Try per-site permissions: Visit the site → click the padlock/site info → Site settings → look for Background sync in that site’s list.
If a site breaks after you block Background sync .
This usually shows up as “queued” actions never sending unless you reopen the site (messages, drafts, uploads). The fix is almost always a targeted allow rule:
- Set global default to Block.
- Add only that site (exact domain) to the Allowed list for Background sync.
- Reload the site and test the workflow again (send a message, submit a form, etc.).
If Chrome keeps running in the background after you close it .
That’s typically not Background sync. It’s usually the System setting Continue running background apps when Google Chrome is closed or an extension/background process issue. Guides and baselines often point to that toggle for reducing background resource use. :contentReference[oaicite:24]{index=24} If you’re seeing high CPU/RAM with Chrome closed, address System settings and extensions first.
If the setting is greyed out or says “disabled by administrator” .
This is a policy enforcement scenario. Your options are:
- If it’s your device: Check whether you’re signed into a managed profile (work/school) that applies policies across devices. :contentReference[oaicite:25]{index=25}
- If it’s a work device: You’ll need an admin to change the relevant policy (and you can use chrome://policy to identify it). :contentReference[oaicite:26]{index=26}
If you suspect malware or a browser hijack .
Background sync is rarely the root cause of an actual infection—but suspicious sites often abuse permissions like notifications and pop-ups. If you’re seeing redirects, new tabs, or aggressive prompts, do a full cleanup routine: remove unknown extensions, reset permissions, and run a reputable scan.
Related: If you suspect infection or hijacking, see Remove Malware.
If you want to reset safely (without losing everything) .
For a clean permissions reset without nuking your entire profile:
- Open Site settings → View permissions and data stored across sites (or equivalent).
- Search for the site and clear only that site’s data/permissions.
- Revisit the site and re-grant only essential permissions (avoid blanket “Allow all”).
FAQ .
-
helpDoes disabling Background sync stop tracking?It helps, but it’s not a complete anti-tracking solution. Background sync removes a specific mechanism for deferred/retry requests via service workers. Sites can still track through other means (cookies, fingerprinting, third-party scripts). Use it as part of a broader privacy baseline (cookies + site permissions + extension hygiene).
-
helpWill blocking Background sync break Gmail, Slack, or web apps?Most major web apps degrade gracefully, but you may lose “offline-first” reliability (queued actions might send only when you reopen the app). The best approach is Block globally and allow only the sites you truly use. If something breaks, add a single-site exception.
-
helpIs Background sync the same as Chrome “Sync”?No. Background sync is a site permission related to service workers and retrying requests. Chrome account sync is Google account-based syncing of bookmarks, passwords, history, etc. If you’re trying to stop account sync, use the Chrome sync settings pages instead.
-
helpWhy is Background sync missing or locked?Common reasons: (1) your device/browser is managed by an organization and policies enforce permissions; (2) your platform (especially iOS) doesn’t expose the same controls; (3) Chrome moved the permission under “Additional permissions.” If you suspect policies, check chrome://policy and look for “Managed by your organization.”
Sources & further reading .
- Google Chrome Help: Change site settings permissions (desktop)
- Google Chrome Help: Change site settings permissions (Android)
- Chrome for Developers: Introducing Background Sync
- MDN: Background Synchronization API
- Chrome for Developers: Periodic Background Sync
- Chrome Releases: Stable Channel Update for Desktop (Chrome 145)
- Chrome for Developers: Chrome 145 release notes
- Google Admin: View a device’s current Chrome policies
Disclosure: Some pages may mention tools or services. Recommendations are editorial and based on testing.