SharePoint Offline and Sync: On vs Off Impact + Slow List Fix

If you have ever opened List Settings → Advanced Settings in SharePoint Online and stared at this question —

“Allow people to sync this list to their computers with Microsoft Lists and access it in the browser without an internet connection?” Yes / No

— and wondered which answer is “correct,” this guide is for you.

I’ll cover exactly what this setting controls, what changes when it’s On (Yes) versus Off (No), how to change it in the UI and with code, and then the question that brings most people here: why does adding an item to the list feel painfully slow in your normal browser, but fast in an InPrivate / Incognito window?

Honesty note up front: Microsoft documents what this setting does, but Microsoft has not published anything linking this setting to slow item creation. I’ll clearly separate documented facts from field experience and reasoned diagnosis throughout. Anyone who tells you “just turn Offline and Sync off and your list gets fast” is guessing. Below is the actual diagnostic path.

Quick answer

	Yes (On) — default	No (Off)
Underlying property	ExcludeFromOfflineClient = false	ExcludeFromOfflineClient = true
Microsoft Lists / offline sync to device	Allowed	Blocked
Browser access without an internet connection	Allowed (data cached locally)	Blocked
Local copy of list data on the user’s device	Yes	No (via official sync)
Users can still export to Excel / copy / screenshot	Yes	Yes — this is not a security control
Best for	Field/offline workers, mobile-first teams, small-to-medium lists	Sensitive lists, very large lists, regulated data, shared/kiosk devices

The one-line verdict: Leave it Yes if people genuinely work offline. Set it No if the list holds sensitive data, if it’s very large, or if nobody ever works disconnected — you lose nothing except a feature nobody uses.

What is the “Offline and sync” setting actually?

The official name behind the friendly label

Under the hood, this is a single boolean property on the SharePoint list object:

Microsoft.SharePoint.Client.List.ExcludeFromOfflineClient  (Boolean)

Microsoft’s own .NET/CSOM API reference documents it here: List.ExcludeFromOfflineClient

The same flag has worn several different names over the years, which is why searching for it is so confusing:

Where you see it	What it’s called
Modern list/library Advanced Settings	Offline and sync
Classic site settings	Offline Client Availability
Classic library settings / OneDrive docs	Exclude from Offline Client
CSOM / REST / PnPjs / CLI for Microsoft 365	ExcludeFromOfflineClient

Watch the inversion. The UI asks a positive question (“Allow… ?”), the property is a negative flag (“Exclude…”). So:

• UI = Yes → ExcludeFromOfflineClient = false
• UI = No → ExcludeFromOfflineClient = true

Getting this backwards in a PowerShell script is the single most common mistake admins make with this setting.

The CLI for Microsoft 365 describes the parameter in plain language:

--excludeFromOfflineClient — “Value that indicates whether the list should be downloaded to the client during offline synchronization.”

What happens when the setting is ON (Yes)

Setting it to Yes — the default for every new list — enables two distinct capabilities bundled into one question:

Sync to the device via Microsoft Lists

The list is eligible to be downloaded to the user’s client during offline synchronization. A local copy of the list’s schema and items can live on the device so the list is usable when the network isn’t.

Browser access without an internet connection

This is the second half of the sentence, and the part people overlook. The modern Lists/SharePoint web experience can keep a local copy of list data inside the browser’s own storage (IndexedDB / cache storage, backed by a service worker) so the list renders when you’re disconnected or on a flaky connection.

This is the key detail for the performance question later in this article. When this is Yes, your browser is being asked to maintain a local mirror of the list. For a small list that’s free. For a large, wide, heavily-edited list, that local mirror is real work the browser must build, store, and reconcile against the server.

Practical impact of ON

Benefit	Cost
Field and travelling users can read (and queue work on) the list offline	Business data lands on local devices, including unmanaged ones
Faster perceived load on repeat visits for small lists (data already local)	Larger local storage footprint in the browser profile
Resilient to brief network drops	More client-side reconciliation work on every page load
Works with Microsoft Lists‘ offline experience out of the box	More moving parts to go wrong (stale cache, sync conflicts)

What happens when the setting is OFF (No)

Setting it to No marks the list as excluded from offline clients:

• The list will not be downloaded to clients during offline synchronization.
• The list cannot be accessed in the browser without an internet connection — no local offline mirror is maintained.
• Everything else works completely normally while online: views, forms, filters, Power Automate flows, Power Apps, permissions, search, Excel export, REST/Graph API access. Nothing breaks.

This is the single most important and most misunderstood point:

Turning “Offline and sync” to No does not restrict, degrade, or limit the list in any way for a connected user. It only removes the ability to use it while disconnected.

What OFF does not do — don’t treat this as a security control

This setting is not data-loss prevention. Microsoft’s own support article that covers it is titled “Limit sync for a SharePoint site” — note the word limit, not prevent. (Tellingly, that article’s original title was “Prevent users from downloading content from a site” — Microsoft renamed it, because it never actually prevented that.)

With the setting at No, a user with Read or Contribute access can still:

• Export the list to Excel
• Open each item and copy the values
• Use the REST/Graph API or Power Automate to extract the data
• Take screenshots

Real data-leak prevention requires different tools: Microsoft Entra Conditional Access session policies (app-enforced restrictions for unmanaged devices) and Microsoft Purview DLP. Those operate at the authentication and content-scanning layers respectively — they are architecturally separate from ExcludeFromOfflineClient and do not depend on it. Use them together as defence in depth; never use this checkbox alone and call the list “secured.”

How to change the setting (UI, REST, CLI, CSOM)

Option A — The UI (per list)

1. Open the list.
2. Click the gear icon (⚙) → List settings.
   (Modern UI: gear → List settings → More settings → Advanced settings.)
3. Scroll to the Offline and sync section.
4. Select Yes or No.
5. Click OK at the bottom of the page.

The change applies immediately on the server. Clients may take a sync cycle to notice.

Option B — Site-collection level (all document libraries in the site)

Site Settings → Search → Search and offline availability → Offline Client Availability → No

This is documented in Microsoft’s Limit sync for a SharePoint site article. Note this classic path governs libraries site-wide; per-list control still lives in Advanced Settings.

Option C — CLI for Microsoft 365 (cleanest scripted method)

m365 spo list set \
  --webUrl https://contoso.sharepoint.com/sites/project-x \
  --title "Project Tasks" \
  --excludeFromOfflineClient true

true = excluded = UI shows No.

Option D — REST (via PnP PowerShell, verified approach)

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/project-x" -Interactive

Invoke-PnPSPRestMethod `
  -Method Merge `
  -Url "/_api/web/lists/getbytitle('Project%20Tasks')" `
  -Content @{ ExcludeFromOfflineClient = $true }

Accuracy caveat worth repeating: you will find blog posts recommending Set-PnPList -Identity "X" -ExcludeFromOfflineClient $true. That parameter is not listed in the current published Set-PnPList cmdlet reference. Verify it against your installed module with Get-Help Set-PnPList -Parameter * before you rely on it in production — or just use the REST method above, which is guaranteed to work.

Option E — CSOM (C#)

List list = web.Lists.GetByTitle("Project Tasks");
list.ExcludeFromOfflineClient = true;   // true = No in the UI
list.Update();
clientContext.ExecuteQuery();

Option F — Bulk audit across a site

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/project-x" -Interactive

Get-PnPList | Select-Object Title, ItemCount, @{
    Name = 'OfflineSyncAllowed'
    Expression = { -not $_.ExcludeFromOfflineClient }
} | Sort-Object ItemCount -Descending | Format-Table -AutoSize

Run this first. You’ll usually discover a handful of large lists with offline sync quietly enabled that nobody ever uses offline.

The real question: why is my list slow to add items — but fast in Incognito?

This is the symptom that sent most readers here:

“When I try to add an item to the list it takes a very long time. But in an InPrivate / Incognito window, I can add it fast.”

Let’s handle this properly, because the honest answer is more useful than a confident wrong one.

First, the critical diagnostic insight

The fact that it’s fast in Incognito is the single most valuable clue you have — and it tells you the bottleneck is on the client, not the server.

Think about what’s identical and what’s different:

	Normal window	Incognito / InPrivate
SharePoint server	Same	Same
List schema, columns, items	Same	Same
Power Automate flows on item creation	Same	Same
Your permissions	Same	Same
Browser extensions	Loaded	Disabled by default
Cache, IndexedDB, service workers	Accumulated over months	Completely empty
Stored auth tokens / multi-account state	Accumulated	Clean sign-in
Browser profile health	Possibly bloated/corrupt	Pristine

If the server were the bottleneck — too many lookup columns, a synchronous flow, a huge view, an event receiver — Incognito would be exactly as slow, because none of those server-side factors change. It isn’t. Therefore the problem lives in the right-hand column.

Key takeaway: “Fast in Incognito, slow in a normal window” almost always means a client-side problem: browser extensions, a bloated local cache, a stuck service worker, or stale authentication state — not a SharePoint list design problem.

Where “Offline and sync” fits in — the reasoned hypothesis

Remember what Yes enables: “access it in the browser without an internet connection.” That capability requires the browser to maintain a local mirror of the list in IndexedDB / cache storage, managed by a service worker.

So the plausible chain of events is:

1. Offline and sync = Yes → the browser builds and keeps a local copy of the list.
2. The list is large, wide, or heavily edited → that local copy is big and changes constantly.
3. On every page load and every write, the client must reconcile local state against the server.
4. The “New item” form and the save operation pay that reconciliation cost → slow adds.
5. Incognito has no local copy at all → there is nothing to reconcile → fast adds.

Be clear about the evidence level here. This mechanism is consistent with how the feature is documented to work and with the Incognito evidence, but Microsoft has not published documentation confirming that enabling Offline and sync causes slow item creation, and there is no dedicated Microsoft article describing the Lists browser offline cache or how to clear it. Treat this as a well-reasoned, highly testable hypothesis — not a documented fact.

The good news: it takes about five minutes to test, and the test is free.

The 5-minute test that settles it

Run these in order. Stop at the first one that fixes the problem.

Test 1 — Rule out browser extensions (2 minutes, highest hit rate)

Extensions are disabled in Incognito by default, which makes them the #1 suspect for any “fast in Incognito” report. In your normal window, disable all extensions, restart the browser, and retest. If it’s fast, re-enable them one at a time. Usual culprits: ad blockers, password managers, corporate endpoint/DLP browser agents, grammar and screenshot tools, and session-recording extensions.

Test 2 — Clear site data for your SharePoint tenant (2 minutes)

This nukes the local cache, IndexedDB store and service worker without wiping your whole browser profile.

• Edge/Chrome: F12 → Application tab → Storage → Clear site data (tick Unregister service workers). Or go to edge://settings/content/all / chrome://settings/content/all, search your tenant domain, and delete its data.
• Reload the list and add an item.

If this fixes it, you have confirmed a local cache problem — which is exactly what the offline feature creates.

Test 3 — Toggle Offline and sync to No, then re-test (1 minute)

Set the list’s Offline and sync to No, clear site data once more (so the old mirror is gone), and add an item. If performance stays good over the following days while a control list left at Yes stays slow, you have your answer for your environment.

Test 4 — Try a different browser profile, not a different browser

A fresh profile isolates profile corruption from browser-engine issues.

Test 5 — Only now, suspect the server. If Incognito is also slow, skip everything above and go to the server-side causes below.

If Incognito is ALSO slow: server-side causes to check

If your private window is just as slow, the bottleneck is on the SharePoint side. Work through these in order of likelihood:

Too many lookup-type columns (the silent killer)

Microsoft’s List View Lookup Threshold is 12, and the documentation is explicit about what counts:

“When SharePoint constructs the list forms, all the fields available for the list item are retrieved from the database. Lists with a large number of Lookup columns might result in complex and potentially intensive SQL statements.”

Critically, it’s not just classic Lookup columns:

“In addition to standard lookup columns, single-value managed metadata, multiple-value managed metadata, single-value people and group columns, and multiple-value people and group columns all count as lookup columns.”

Count your Person, Managed Metadata and Lookup columns right now. Three Person columns + four Managed Metadata columns + six Lookups = 13, and your New Item form is doing 13 SQL joins on every single open and save. This is the most common cause of genuinely slow forms that people never think to check.

Fix: replace low-value Lookup/Person columns with plain Choice or Text columns where the relationship isn’t actually used.

The 5,000-item List View Threshold

Microsoft documents it directly:

“You can store up to 30 million items or files in a list or library. However, as the number of items increases, you might notice that certain operations take longer. When a list view shows more than 5,000 items, you might run into a list view threshold error.”

And the reason:

“To minimize database contention, SQL Server… often uses row-level locking… However, if a read or write database operation… causes more than 5,000 rows to be locked at once, then it’s more efficient for SQL Server to temporarily lock the entire table…”

Fix: add indexed columns, filter your default view to return under 5,000 rows, and archive old items.

Power Automate flows triggered on item creation

A flow on When an item is created shouldn’t block the save — but a flow with a synchronous request/approval pattern, or several flows firing at once, absolutely can make the experience feel stuck. Temporarily turn flows off and retest.

Custom event receivers (classic/on-premises and legacy solutions)

Event receivers on ItemAdding/ItemAdded run synchronously on the save path. Community reports describe multi-minute saves on lists of only ~6,000 items that traced back to exactly this.

Heavy JSON column/view formatting

Column and view formatting is rendered client-side for every row. Complex formatting with images, conditional logic and nested structures multiplies across a large view. Test with a clean, unformatted view.

Other accumulated weight

• Excessive versioning history (cap major versions at a sane number, e.g. 50–500)
• Dozens of columns beyond what the form actually needs
• Large attachments on every item
• Too many content types inflating the list schema

So should you set it to Yes or No? A decision framework

Set it to No (disable offline sync) when:

• The list contains sensitive, confidential or regulated data (HR, finance, customer PII, legal)
• The list is large (thousands of items) or wide (many columns) — the local mirror costs the most here and gains you nothing
• Nobody actually works offline with this list (this is most lists, in most organisations)
• Users access it from shared, kiosk or unmanaged devices
• You’re troubleshooting a slow list and want to eliminate a client-side variable
• Your organisation has data-residency or device-compliance obligations

Keep it Yes (allow offline sync) when:

• You have genuine field workers — inspections, site surveys, deliveries, warehouses, aircraft, basements, rural sites
• The list is small to medium and relatively stable
• The data is low sensitivity (room bookings, equipment catalogues, public reference data)
• Network reliability is poor and resilience outweighs the overhead

The pragmatic default most admins should adopt

Turn it off by default on new sensitive and large lists; turn it on deliberately, per list, when somebody can name a real offline scenario. Features enabled “just in case” are the ones that cost you performance, storage and risk with zero return.

Frequently asked questions

Your action checklist

• Run the PowerShell audit in Option F above to see which lists have offline sync enabled
• Set Offline and sync to No on sensitive and large lists
• For your slow list: test in Incognito first — this is your most important diagnostic step
• If Incognito is fast → disable browser extensions, then clear site data/IndexedDB/service workers
• If Incognito is also slow → count Lookup + Person + Managed Metadata columns (limit: 12)
• Add indexed columns and filter default views below 5,000 items
• Review Power Automate flows and event receivers firing on item creation
• Cap version history and remove unused columns
• Layer Conditional Access + Purview DLP for genuine data protection — never rely on this checkbox

You May Also Like

• How to create a SharePoint site
• SharePoint document library best practices
• How to create a SharePoint folder
• SharePoint permissions best practices
• What is Microsoft Lists?