SharePoint Version History Storage: Find & Reduce It (2026)

Why Version History Consumes So Much SharePoint Storage

In SharePoint Online, every version of a file is stored in full and counts against your tenant storage quota. There is no delta compression - a 10 MB file that has been edited 50 times can consume around 500 MB of storage on its own. Multiply that across every actively edited document in a large tenant, and version history is frequently the single largest consumer of SharePoint storage, often larger than the current versions of the files themselves.

Because SharePoint charges $0.20 per GB per month ($2,400 per TB per year) for storage above your pooled allocation of 1 TB plus 10 GB per licensed user, unmanaged version history translates directly into a recurring bill. This guide explains how version limits work in 2026, why they do not clean up what you already have, and exactly how to reclaim the space - verified against Microsoft's current documentation.

How Version Limits Work in 2026

Microsoft now offers three version storage modes, and Automatic is the default and recommended setting for new document libraries.

Automatic limits (recommended)

Also called intelligent versioning, the automatic mode thins out older versions using an algorithm based on the principle that a version's restore value declines as it ages. Under automatic limits, users retain:

• All versions created within a 500-count limit in the first 30 days.
• Hourly versions (the version created at the top of each hour) between 30 and 60 days.
• Daily versions (the first version of each day) between 60 and 180 days.
• Weekly versions (the first version of each week) beyond 180 days, kept indefinitely until the maximum 500-count limit is reached.

Microsoft reports that automatic limits reduce version storage by roughly 94-96% over a six-month period compared with fixed count limits, while still giving users access to high-value recent versions. To set automatic limits as the organisation default for all new libraries, an administrator runs:

Set-SPOTenant -EnableAutoExpirationVersionTrim $true

Manual limits (count, with or without expiration)

You can instead set a fixed number of major versions to keep, optionally combined with an expiration period. Manual count-plus-expiration gives the lowest, most predictable storage footprint - versions older than the expiration are deleted - but it can trim all versions of files that are not edited for a long time. Manual count-only keeps a set number of versions regardless of age, which is predictable but can consume the most storage on heavily edited files.

The Catch: Limits Do Not Trim Existing Versions

This is the point that surprises most administrators. Setting or lowering a version limit only applies to new versions going forward. It does not retroactively delete the existing version history already consuming your quota.

If you lower a library's limit, SharePoint trims the excess gradually - roughly 20 versions are removed per file each time that file is next updated - so files that are never edited again keep their full history forever. To actually reclaim space from existing content, you have to queue a trimming job.

How to Reclaim Space: Trim Existing Versions

Microsoft provides PowerShell cmdlets to trim existing version history at site or library scope. Before running anything, note the serious caveat:

Versions deleted by a trimming job are permanently deleted. The deletion bypasses the recycle bin and cannot be recovered. Run a What-If impact analysis first.

Step 1: Run a What-If analysis first

Before committing, generate a version storage usage report and run a What-If analysis to preview how much space each trim mode would reclaim and how many versions users would lose. Depending on the size of the site or library, this job can take a few days to complete. Do not skip it - trimming is irreversible.

Step 2: Queue the trim job

Connect with the latest SharePoint Online Management Shell as a SharePoint Administrator, then queue one of the following jobs.

Trim by the automatic algorithm (recommended - mirrors intelligent versioning):

New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -Automatic

Trim versions older than a set age (the value must be 30 days or more, and cannot keep anything created before 1 January 2023):

New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -DeleteBeforeDays <days>

Trim versions exceeding a major version count:

New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -MajorVersionLimit <count>

To scope a job to a single library instead of a whole site, use the list-level equivalent:

New-SPOListFileVersionBatchDeleteJob -Site $siteUrl -List $libName -Automatic

Step 3: Track progress

Trim jobs run asynchronously as background jobs, subject to off-peak processing, so they are not instant. Track them with:

Get-SPOSiteFileVersionBatchDeleteJobProgress -Identity $siteUrl

For a library-level job, use Get-SPOListFileVersionBatchDeleteJobProgress -Site $siteUrl -List $libName. If you need to stop a job in progress, Remove-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl halts further deletions (already-deleted versions stay deleted).

Where Version History Fits in a Storage Strategy

Trimming version history is usually the single biggest one-time reduction available to a SharePoint tenant, which is why it leads any serious reduce SharePoint storage effort. But it is a trade-off: every version you trim is a recovery point you give up permanently, and there is a floor below which you should not go for compliance and undo-protection reasons.

Archiving takes a different approach to the same storage problem. Instead of deleting version history, Squirrel moves entire inactive files - current version and history intact - out of the SharePoint storage pool and into your own Azure Blob Storage at a fraction of the SharePoint rate. A stub stays behind so users can still find and restore the file. For inactive content, that reclaims the storage without destroying any versions, and the data lands in storage your organisation owns rather than being permanently purged.

In practice the two are complementary: trim version history on active libraries to control ongoing growth, and archive inactive content to Azure so it stops paying the SharePoint premium at all. See SharePoint Online archiving for the full picture.

Frequently Asked Questions

Does version history count against SharePoint storage? Yes. Every version is stored in full and counts against your tenant quota. A file edited many times can consume many times its current size in version history alone.

What is the default version limit in SharePoint Online? For new document libraries, Microsoft defaults to Automatic (intelligent) version limits, which retain all versions for the first 30 days, then progressively thinner sets of hourly, daily, and weekly versions up to a maximum of 500 versions. This reduces version storage by roughly 94-96% over six months compared with fixed count limits.

Why did lowering my version limit not free up space? Version limits only apply to new versions. Existing version history is not deleted retroactively - SharePoint trims excess gradually as files are next edited. To reclaim space from existing versions immediately, queue a trimming job with New-SPOSiteFileVersionBatchDeleteJob.

Can I recover versions deleted by a trimming job? No. Trimming jobs permanently delete versions and bypass the recycle bin. Always run a What-If impact analysis before trimming.

Can I reduce version storage without deleting versions? Yes - archive inactive files to lower-cost storage instead. Squirrel moves inactive documents, with their version history intact, into your own Azure Blob Storage and leaves a stub in SharePoint, so you reclaim the pool without permanently losing recovery points.

Related reading

• How to reduce SharePoint Online storage
• How to find your largest SharePoint sites
• How many versions does SharePoint keep?
• Every SharePoint Online limit in 2026
• SharePoint Online archiving - the complete enterprise guide

Reclaim the Space Without Losing the Files

Trimming version history frees storage but costs you recovery points. Archiving frees the same storage and keeps the files - in your own Azure. See how Squirrel cuts SharePoint storage costs, or contact us to review your tenant's version storage.