A single Excel workbook under active co-authoring can accumulate more than 200 version entries in a single project sprint. That is not a malfunction; it is SharePoint Online working exactly as designed. The version history problem most admins associate with long-lived documents turns out to be even more aggressive in heavily collaborative files, and the mechanism behind it is one that many organisations only discover when a library's quota runs out.
What version history captures during a co-authoring session
SharePoint Online records a version of a file each time the document is saved. In co-authoring, Office applications use AutoSave to write changes back to SharePoint at short intervals so that each participant always sees a near-current version of the document. AutoSave does not wait for a user to press Ctrl+S; it pushes changes automatically, on a cadence tied to detected edits rather than to user action.
The result is a much higher save frequency than in traditional sequential editing. Where a single user might save a document explicitly ten or twenty times in an afternoon, an actively co-authored document will trigger save events dozens of times per hour across the session. Each of those save events can create a version entry in the file's history.
What determines whether an AutoSave write creates a version: libraries configured to track only major versions create a version on each qualifying save cycle. Libraries configured to track both major and minor versions create minor versions at the AutoSave frequency and promote them to major versions when a user checks in or explicitly publishes. In practice, the minor version count in a co-authored major-and-minor library grows faster than most admins expect during any period of active collaboration.
Why co-authored files accumulate more versions than single-user documents
The AutoSave interval and save frequency
AutoSave fires whenever the Office application detects pending changes and the cloud save queue is ready. When multiple users are actively editing simultaneously, the queue runs almost continuously. The result: co-authored sessions create significantly more save events per unit of time than sequential single-user editing, even when the total volume of content change is the same.
For non-Office file types stored in SharePoint document libraries (PDFs, images, ZIP files, video), co-authoring does not apply in the same way, but libraries that hold a mix of types will still show inflated version counts on the Office files while the non-Office files accumulate versions only on explicit upload or overwrite.
The compounding effect of multiple contributors
In a team of six people editing a shared document over a five-day sprint, each team member's session contributes save events independently. When three people are editing simultaneously, the save frequency during those overlapping windows is effectively additive - the version count climbs faster than any single person's editing pace would suggest. A project library in active use will routinely reach version counts an order of magnitude higher than the same library during a quiet period.
The default 500-major-version limit means a file can absorb this load for some time before the cap triggers and the oldest versions are discarded. For minor versioning libraries, the per-file minor version limit is separate from the major version limit, and reaching several hundred minor versions on a single file in a week of active co-authoring is common and often goes unnoticed.
The storage consequence across active collaboration sites
For Office documents (Word, Excel, PowerPoint), SharePoint uses delta storage between versions: each version records only the changes from the previous one rather than a full copy. This is more efficient than storing complete copies for every save, but it does not make the storage cost negligible, particularly on large files with heavy per-session change volumes.
A realistic estimate: an actively co-authored Excel model with 200 saved versions, each averaging 150 kilobytes of delta content, holds roughly 30 megabytes of version history above a current working file size of 2 megabytes. A project library with 80 such models accumulates approximately 2.4 gigabytes in version history. Across a department running several active project libraries in parallel, the cumulative version storage often becomes the largest single line item in the site collection's footprint.
| Library type | Versioning setting | Expected version accumulation during active co-authoring |
|---|---|---|
| Project collaboration library | Major and minor versions, limit 50 major | High: 30-80 minor versions per file per active editing day; major count grows at each check-in |
| Document management library | Major versions only, limit 500 | Moderate: 5-20 major versions per file per active editing day depending on AutoSave frequency and change detection |
| Intranet or publishing library | Major and minor, limit 10 major | Low: infrequent edits; version limit caps accumulation before it becomes a storage concern |
| Image or media library | Major versions only | Very low unless files are frequently replaced via upload |
Microsoft Intelligent Versioning and the co-authoring problem
Microsoft introduced Intelligent Versioning for SharePoint Online in late 2024. The feature automatically thins version history by preserving a manageable set of versions over time rather than keeping every version indefinitely up to the configured limit. It targets the long tail: versions from weeks or months ago are thinned more aggressively than recent ones, so a library with an extended co-authoring history will see its older version counts reduce gradually without manual intervention.
The limitation is timing. Intelligent Versioning does not address the burst of recent versions created during an active sprint that has just concluded. If a project wraps up and the document library contains thousands of minor versions from the final push, those versions will be preserved well within the Intelligent Versioning window before qualifying for automatic thinning. Admins already approaching a quota ceiling and needing to reclaim storage now, rather than over the coming months, still need a proactive trim.
For context on how Intelligent Versioning interacts with manual version policies and what the setting actually controls, see the guide to trimming SharePoint version history.
Practical steps for admins managing co-authoring version accumulation
Find which libraries and files are the heaviest contributors
The SharePoint admin center shows total storage per site but does not break down how much of that figure is version history versus current working content. Identifying the libraries that need attention first requires either PnP PowerShell queries (Get-PnPListItem can return version counts per file for a given library) or a reporting tool. Report Master generates an Excel export that includes version counts per file across all site collections, giving you a ranked view of where version storage is concentrated across the tenant in a single run.
Once you know which libraries carry the most version overhead, you can target trimming where it will reclaim the most storage with the least operational risk.
Apply a bulk trim to accumulated co-authoring history
The most effective lever is a keep policy: retain the most recent 20 major versions per file and delete anything older than 60 days beyond that set. This approach preserves the working history teams actually use for recovery while removing the dense band of autosave versions from editing sessions months past. For minor versions in a major-and-minor library, a more aggressive trim is usually safe: teams rarely need to recover a minor draft version from more than a week ago.
Native SharePoint has no cross-library bulk version trim. PowerShell can do it file by file, but running it safely across a production library with thousands of files requires careful scripting and staged testing. Space Master's Version Trimmer lets you configure the keep policy and execute the trim across all connected libraries without touching the current working version of any file.
Set a sensible versioning policy before the next collaborative sprint
For new project libraries intended for intensive co-authoring, switching to major versions only rather than major and minor significantly reduces the total version count by eliminating the tier where AutoSave accumulates most aggressively. The tradeoff is that draft states are no longer individually tracked: only each explicit check-in creates a version. For most project work where teams care about daily snapshots rather than every autosave checkpoint, this tradeoff favours storage efficiency without meaningfully reducing recovery options.
Setting the major version count limit to a number matched to actual recovery needs (10 to 30 for most project work, higher for regulated or approval-tracked content) is more operationally meaningful than leaving the default at 500. The default is generous enough that it almost never triggers naturally, which means it never does the job of managing accumulation; it simply defers the problem.
Frequently Asked Questions
Does SharePoint Online create a version every time AutoSave fires during co-authoring?
Not at every single AutoSave event, but yes in practice. SharePoint records a version at intervals as AutoSave pushes changes. For libraries tracking major and minor versions, each save interval during co-authoring typically creates a minor version. For major-only libraries, versions are recorded less frequently but still accumulate measurably during active sessions.
How can I reduce the number of versions created during co-authoring sessions?
The most effective change is switching high-activity libraries from major and minor versioning to major versions only. This cuts out the minor version tier where AutoSave accumulates most aggressively. A lower major version count limit also prevents unchecked accumulation going forward. For existing accumulated history, Space Master's Version Trimmer applies a configurable keep policy in bulk across all libraries.
Does Microsoft Intelligent Versioning help with co-authoring version accumulation?
Partially. It automatically thins older versions over time, which reduces long-tail accumulation from historical editing periods. However, it does not immediately clear recent versions from a sprint that has just concluded. Admins already close to a quota limit may need a proactive trim before Intelligent Versioning works through the recent backlog.
How do I find which SharePoint files have the most version history in a library?
The SharePoint admin center does not expose per-file version counts. PnP PowerShell can query them per library with Get-PnPListItem. Report Master generates an Excel export with version counts per file across all libraries in a site collection, which is faster for identifying tenant-wide accumulation patterns.