Exploring SharePoint Files and List Item Versioning

SharePoint Document Versioning automatically saves iterations of a document as it changes, so you can see who changed what and restore an earlier version if something goes wrong.

In this post: Enabling versioning · Managing version history · List item versioning · What “restore” actually does · Intelligent Versioning: automatic trimming · How many versions should you actually keep? · Managing versioning with PnP PowerShell · When would you actually use this? · Related reading

Enabling versioning

Go to the document library where you want versioning.
Open Library Settings.
Under General Settings, select Versioning Settings.
Choose the type: No Versioning (only the latest copy is stored), Major Versions Only (1.0, 2.0 — for finalized documents), or Major and Minor Versions (1.0, 1.1, 1.2, 2.0 — for drafts and continuous updates).
Set how many versions to retain, to keep storage in check.
Save.

Managing version history

Right-click a document and select Version History to see past versions and what changed.
Select an older version and click Restore to revert to it.
Delete old versions manually, or let retention policy handle it automatically.

List item versioning — not just files

Versioning isn’t only a document library feature — SharePoint lists (task lists, custom lists, anything built on list columns) support the same major-version history independently. Turn it on the same way: List Settings > Versioning Settings > Create a version each time you edit an item in this list. This matters more than it sounds like it should, because list items don’t have a “file” to reopen and compare — version history is often the only record of who changed a status, a due date, or an approval field, and when. If you’re using a list to drive an approval workflow (a “Status” column a Power Automate flow watches, for example), turning this on gives you an audit trail of every status change, not just the current value.

What “restore” actually does

Worth knowing this precisely, since “restore” sounds like it reverts time backward but doesn’t: clicking Restore on an older version doesn’t delete anything that came after it or roll the version number back down — it copies that older content forward and saves it as a brand-new version at the top of the history. Restoring version 2.0 on a document currently at version 5.0 doesn’t bring it back to “2.0” — it creates version 6.0, containing version 2.0’s content, with versions 3.0 through 5.0 still sitting in history exactly as they were. Nothing is destroyed by a restore, which is worth knowing before treating it as a risky, one-way action — it’s genuinely safe to try, since every version restored away from is still sitting there afterward if the restore itself turns out to be the wrong call.

Intelligent Versioning: automatic trimming

SharePoint Online libraries default to keeping up to 500 major versions per document — fine until a frequently-edited file actually hits that ceiling. Microsoft’s newer Automatic versioning mode handles this with time-based thinning instead of a hard cutoff: every version from the last 30 days is kept in full, then it steps down to one version per hour for 30-60 days old, one per day for 60-180 days, and one per week beyond that — all within the same 500-version cap. Microsoft’s own reporting shows this cutting version-history storage by up to 96% over six months compared to keeping everything until the limit forces deletions. It’s set per library (or tenant-wide as a default) alongside the regular versioning settings, and it’s worth turning on for any library where “who changed this three months ago” matters more than “every single edit from three months ago.”

How many versions should you actually keep?

5-10 versions for fast-changing documents like drafts and work-in-progress files.
25-50 versions for regulatory documents that need an audit trail.
Unlimited only for critical files with long-term compliance needs — contracts, legal documents.
Turn on auto-cleanup so old versions get dropped once the limit is hit, instead of storage growing unchecked.

Managing versioning with PnP PowerShell

Clicking through Library Settings on every document library across a site (or every site across a tenant) doesn’t scale. Setting a version limit on one library is a single cmdlet:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

# Major versions only, capped at 50
Set-PnPList -Identity "Documents" -EnableVersioning $true -MajorVersions 50

# Major and minor versions, with separate caps for each
Set-PnPList -Identity "Documents" -EnableVersioning $true -EnableMinorVersions $true -MajorVersions 500 -MinorVersions 100

The Automatic (Intelligent Versioning) trimming mode covered above is a site-level policy, set with a different cmdlet — and it can be retrofitted onto libraries that already exist, not just new ones:

# Turn on automatic time-based trimming for the site, including existing libraries
Set-PnPSiteVersionPolicy -EnableAutoExpirationVersionTrim $true -ApplyToExistingDocumentLibraries

Loop the first script across every library in a site (or every site in a tenant, via Get-PnPTenantSite) to standardize retention limits in one pass instead of a library-by-library manual settings check.

The tradeoff is storage and performance — set a version limit that matches the actual retention need, not the default.

When would you actually use this?

Someone overwrote a document with the wrong content and you need what was there yesterday — version history is the fix, assuming versioning was already turned on.
You’re in a regulated industry and need to prove who changed a document and when — this is the audit trail, and it’s why compliance and governance policies usually mandate it.
A library’s storage is bloating and nobody knows why — uncapped versioning on a large, frequently-edited library is a common, invisible cause.
Multiple people are editing the same document and you need a clear record of who changed what, without anyone’s work silently overwriting someone else’s.

The tradeoff is storage and performance — large libraries with unlimited versioning and no cleanup policy will eventually feel it. Set a version limit that matches the actual retention need, not the default.

How to Delete File and List Versions in SharePoint — the cleanup step once your version history has grown past what’s useful.
Extracting SharePoint File Version History Using PowerShell — pull the version data covered here in bulk instead of checking files one at a time.

That should do it. Let me know in the comments if something’s not working for you.