SharePoint Online stores a full copy of a file for each version, not a diff. A 10 MB presentation with 50 versions consumes 500 MB of version storage alone, before the current file is counted. This reference page covers how that calculation works, which file types behave differently, and which settings allow admins to control the accumulation.
The Full-File Storage Model
For the vast majority of file types stored in SharePoint Online document libraries, each version is stored as a complete, independent copy of the file. SharePoint does not compute a binary delta between versions and store the diff. This design prioritises restore reliability: every version can be opened or restored without needing to chain diffs from the original.
The practical implication is straightforward: version storage equals average file size multiplied by the number of versions retained. For large files or files with many small edits, this accumulates quickly.
| File | Average size | Versions retained | Total version storage |
|---|---|---|---|
| Spreadsheet | 5 MB | 100 major versions | 500 MB |
| Engineering drawing | 20 MB | 30 versions | 600 MB |
| Video file | 150 MB | 10 versions | 1.5 GB |
| Text file | 2 KB | 500 versions | ~1 MB |
What About Office Files?
Microsoft has introduced a partial delta model for some Office file formats (Word, Excel, PowerPoint) synced via the OneDrive for Business sync client. Under this model, the sync client uploads only changed portions of the file, and SharePoint reassembles the full file for that version from stored segments. The stored unit on SharePoint's backend may be smaller than the full file size.
From an admin quota perspective, treat every version as a full-file copy. The SharePoint admin center storage reports and site collection storage pages reflect the full-file model. Even if the backend stores delta blocks internally, the quota consumption you observe in the admin center and in site storage reports reflects uncompressed full-file sizing. Budget and plan on this basis.
What Counts as Version Storage
| Content type | Counts toward version storage? | Notes |
|---|---|---|
| Major versions of files in a library | Yes | Each major version (1.0, 2.0, 3.0...) stored as a full copy |
| Minor (draft) versions | Yes | 0.1, 0.2, 1.1, 1.2... each stored when minor versioning is enabled. Co-authoring saves can generate minor versions rapidly. |
| Current (published) version | Yes | The current version is part of the version chain and is counted in the version total, not stored separately |
| Files in the Recycling Bin | Yes | Deleted files and their full version chains remain in the Recycling Bin and count against quota until permanently deleted |
| List item version history | Minimal | List item versions store metadata column values only, not file content. Storage impact is negligible except for very large lists with many columns. |
| Site Pages (modern pages) | Yes | Pages in the Site Pages library version like any other document. Each page snapshot includes embedded web part configurations. |
| OneNote notebooks | Yes | OneNote files sync frequently and can accumulate many versions quickly, especially in active team notebooks |
| Image files in site assets or libraries | Yes | Images uploaded to document libraries or site assets version independently of the pages or documents that reference them |
| Individual version deleted from the version history panel | Freed immediately | Deleting a specific numbered version via the version history panel permanently removes it. Storage is reclaimed at once without going through the Recycling Bin. |
Version Count Settings and Storage Impact
Library-level version settings are the primary lever for controlling version storage accumulation. New libraries pick up the tenant-level defaults; existing libraries keep their current settings until you explicitly change them.
| Setting | Default (new libraries) | Storage impact |
|---|---|---|
| Major version limit | 500 major versions | High. 500 versions of a 10 MB file = 5 GB for that one file's version chain alone |
| Minor (draft) version limit | No minor versions by default; up to 511 drafts per major when enabled | Very high if enabled on active editing libraries without a limit. Each co-authoring save can create a minor version. |
| Keep only last N versions | Not set (keep all versions) | Setting this to 10 or 20 caps accumulation. Older versions are purged automatically when a new version pushes the count past the limit. |
| Automatic version trimming (Intelligent Versioning) | Off by default; optional opt-in per library or tenant | When enabled, Microsoft thins older version chains automatically - keeping more versions of recent changes and fewer of older ones. Reduces accumulation without admin intervention. |
When Version Storage Is Actually Freed
Reducing a library's version count limit does not immediately delete older versions. SharePoint applies the new limit when the next version is saved: the oldest version beyond the limit is then purged. A library with 400 versions and a newly applied limit of 50 still holds all 400 until the file is next edited.
To free storage without waiting for the next edit, you must actively trim versions. Options are: selecting versions in the version history panel and deleting them one file at a time, or using a bulk tool that applies trim rules across many files simultaneously. For tenant-scale trimming, ShareMaster's Version Trimmer applies count rules across an entire site or set of sites in a single operation and can be scoped to versions older than a specified date to preserve recent history. See how to trim SharePoint version history for the step-by-step process.