Learn how SharePoint versioning works, why it impacts storage so heavily, and how to configure versioning settings at tenant and library level to stay in control.
Uncontrolled SharePoint versioning is one of the fastest ways to burn through your Microsoft 365 storage quota. Every edit creates a full copy of a file, and without proper SharePoint versioning settings, version history quietly grows into terabytes of wasted space.
every file version is a full copy
version limits can be set manually or automatically
defaults are configured at tenant level
site owners can override versioning per library
existing libraries are not retroactively fixed
version sprawl must be cleaned up separately
In our article SharePoint large file versions you can read how to identify large files with versions and why it is important.
SharePoint versioning settings define how many versions of a file are kept and for how long. Every time a file is edited in SharePoint, a new version is created. This enables:
restore of previous versions
change tracking
auditability
That’s the upside. The downside is the SharePoint storage need. Versioning is enabled by default and often left untouched for years.
SharePoint does not store only the changes between versions. Each version is a complete copy of the original file at that moment.
Version 1: PowerPoint file, 80 MB
Version 2: Video added → PowerPoint file grows to 1.5 GB
Versions 3–50: only text edits added → each Version is 1.5 GB
Even though the content barely changes, each version still consumes 1.5 GB. If four users edit that file weekly, you can easily hit hundreds of GB per year for a single document. Multiply that across Teams sites, project libraries, and OneDrive accounts and storage costs spiral fast. If you want to learn more about storage costs, we recommend you to read more about it here: SharePoint storage guide.
Version history limits can be configured in two places:
These settings define the default behavior for:
New SharePoint libraries
New OneDrive accounts
They do not change existing libraries.
Each document library can override the tenant default. This is powerful but also dangerous, because site owners often increase limits “temporarily” and never roll them back.
Manual settings give you explicit control. You can define:
Maximum number of versions (100–50,000)
Automatic deletion of versions older than:
3 months
6 months
12 months
Or a custom period (minimum 29 days)
Highly regulated content
Legal or audit-driven libraries
Low-change, high-value documents
We also wrote an article about how to delete file versions in SharePoint versions if you need more details.
Open SharePoint Admin Center
Go to Settings → Version history limits
Select Manual
Define:
Version count
Time-based deletion rules
Save changes
These settings apply only to newly created libraries.
Open the document library
Go to Library settings
Select Versioning settings
Configure:
Version count limit
Version age limit
Click OK
This immediately affects that library.
Automatic versioning uses Microsoft’s internal algorithm to decide which versions are worth keeping. The principle is simple: the older a version is, the less likely it is to be restored. The system gradually removes low-value versions while keeping:
Recent versions
Frequently restored versions
Versions with higher restore probability
Less admin effort
Safer defaults for large tenants
Reduced risk of accidental data loss
Less transparency
Less predictability
No strict version count guarantee
SharePoint Admin Center
Settings → Version history limits
Select Automatic
Save and confirm
Open Library settings
Go to Versioning settings
Set version time limit to Automatic
Save
No version count needs to be defined.
Changing SharePoint versioning settings does not clean up existing versions.
If a library already contains thousands of versions per file, those versions remain until:
They age out (if time-based deletion applies)
You actively remove them
This is why many tenants see no immediate storage relief after “fixing” versioning settings.
If you want predictable storage growth, follow these rules:
Set tenant defaults early
Avoid unlimited versions
Use automatic limits for general libraries
Use manual limits only where justified
Audit libraries with custom overrides
Regularly review version-heavy libraries
Versioning is a safety net, not a storage strategy.
SharePoint versioning settings are one of those “set it once, regret it forever” configurations. Left unmanaged, they quietly inflate storage, drive up costs, and create performance issues, especially in Teams-connected libraries. Configured correctly, they strike the right balance between collaboration safety and cost control. If your storage keeps growing and you “can’t explain why,” version history is almost always part of the answer.
To understand the financial impact, admins can calculate current SharePoint storage costs and potential savings using the SharePoint cost calculator.