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, why Office files are no exception, and which settings allow admins to control the accumulation.
The Full-File Storage Model
For every file type stored in SharePoint Online document libraries, Office files included, 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?
Office files (Word, Excel, PowerPoint) synced via the OneDrive for Business sync client use differential sync: the client uploads only the changed portions of the file, and SharePoint assembles a complete file for that version. That saves upload bandwidth, not storage. Each version is still stored and counted at its full size, Office files included.
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: the quota consumption you observe in the admin center and in site storage reports reflects full-file sizing for every version. 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.
Related References
- SharePoint Online versioning defaults reference
- SharePoint version metadata fields reference
- SharePoint storage consumption: what counts reference
- SharePoint Recycling Bin retention reference