SharePoint Version History: Limits, Storage & Restore
SharePoint’s version history is part of Microsoft 365’s built-in data protection: it lets users view or restore an earlier version of a file, whether they are undoing an accidental edit or recovering from ransomware, and it keeps an audit trail of who changed what (Microsoft Learn). For admins, the practical questions are narrower: how many versions SharePoint keeps, what that costs in storage, and what you can still restore. Here’s the short answer:
- The default : SharePoint Online ships with a manual limit of 500 major versions per file and no expiration. That default applies to every new document library unless you change it [1].
- The ceiling : you can configure 100–50,000 major versions in the admin center. Minor versions are capped separately at 511 per major version, and that cap can’t be changed [2].
- The storage cost : every retained version is a full copy of the file, which makes version history one of the main drivers of SharePoint storage growth [3].
- The fix Microsoft recommends : switch to automatic version history limits, which thin versions out by age instead of by count — roughly a 96% reduction in version storage over six months compared with count limits alone [4].
- The catch : versions removed by a limit or a trim job bypass the recycle bin and can’t be recovered. Only versions a user deletes by hand land in the site recycle bin [5].
Quick Comparison of Version Management Options
| Feature | What It Does | Best For |
|---|---|---|
| Major Versions | Tracks finalized updates | Published documents |
| Minor Versions | Logs drafts and interim changes | Work in progress |
| Automatic Versioning | Retains critical versions dynamically | Frequently updated files |
| Custom Retention Rules | Deletes older versions based on timeframes | Compliance and storage control |
To maximize SharePoint’s versioning capabilities, configure settings to fit your team’s needs, use detailed version comments for clarity, and conduct regular audits to ensure compliance and optimized storage.
How SharePoint Versioning Works
SharePoint’s versioning system ensures document changes are tracked and stored efficiently, so no updates are lost. It uses two types of versions to manage document updates:
| Version Type | Purpose | Best Used For |
|---|---|---|
| Major Versions | Captures finalized updates | Published documents, official releases |
| Minor Versions | Tracks drafts and interim changes | Work in progress, review stages |
Each time a document is edited and saved, SharePoint creates a new version, recording details like who made the change and when. If the library uses automatic version history limits, SharePoint also thins the history out over time — keeping recent versions in full and progressively fewer older ones — rather than waiting for storage to run low [4].
By understanding these version types, administrators can configure settings to align with their document management goals.
Setting Up Versioning Options
Administrators can fine-tune SharePoint’s versioning settings to match organizational priorities. Key configuration options include:
- Where to set it : in the SharePoint admin center, go to Settings > Version history limits and choose Automatically or Manually. The PowerShell equivalents are
Set-SPOTenant -EnableAutoExpirationVersionTrim $truefor automatic, or-MajorVersionLimitplus-ExpireVersionsAfterDaysfor manual [1]. - Version Limits : the tenant default is 500 major versions with no expiration; the admin center accepts 100–50,000 major versions [1].
- Expiration Settings : with the manual setting you can pair a count limit with an expiration period, so versions are deleted once they exceed either. Fast-moving projects might retain versions for 3 months, while regulatory documents could keep them for a year — the UI minimum is 30 days [1].
- ⚠ It only applies to new libraries : changing the organization-level limit does not update existing libraries and does not trim versions that already exist. To align existing content you have to set limits per site or library and queue a trim job [1].
Before you change anything tenant-wide, run a “what-if” analysis report on a site or library: it shows what automatic or manual limits would actually trim, so you can size the change before you make it [4].
Viewing and Managing Version History
SharePoint offers tools to track and manage document changes, making it easier to stay organized and maintain clarity in your workflow. Here’s how you can make the most of its version history features.
How to View Version History
Accessing version history in SharePoint is straightforward. Head to your document library, select the file, and click ‘Version History’ in the menu. A side panel will appear, showing all previous versions along with timestamps and the names of those who made the changes.
For developers, SharePoint also supports REST API access, enabling automated version tracking and integration with other tools.
Restoring or Deleting Versions
Restoring and deleting versions in SharePoint is designed to maintain data integrity. When you restore a previous version, the current version is automatically saved in the history, so no data is lost.
| Action | Impact | Considerations |
|---|---|---|
| Restore Version | Creates a new current version | Current version moves to history |
| Delete Version | Removes a specific version | Goes to the site recycle bin; recoverable for a period |
| Bulk Delete / trim job | Removes multiple versions | Bypasses the recycle bin — permanent |
The distinction matters. A version a user deletes by hand from a file’s version history goes to the site recycle bin and can be restored for a period. Versions removed because they exceeded the library’s limit, or by a scheduled trim job, are permanently deleted and never reach the recycle bin [5]. Files under a retention policy or eDiscovery hold are the exception: versioning limits are ignored for them until the hold is released [5]. Always double-check compliance and retention policies before performing bulk deletions. Adding comments to versions can also help retain important context during these processes.
Detailed comments are key to tracking a document’s changes and ensuring smooth collaboration. Instead of generic notes like “Updated content”, aim for specific descriptions, such as: “Incorporated Q4 financial projections and updated executive summary per CFO feedback.”
Helpful version comments should include:
- The purpose of the changes
- Who requested or approved them
- Relevant context for future reference
- Any effects on related documents or workflows
Comments matter more once automatic limits are in play: as older versions are thinned out, the ones that survive are the only record of what changed, so a version whose comment says nothing is a version nobody can interpret later [4].
Advanced Features of SharePoint Versioning
SharePoint’s automatic version history limits (the feature that rolled out as “intelligent versioning”) change how a library’s history is pruned: instead of keeping a flat count, SharePoint thins versions out as they age, on the principle that a version’s restore value drops over time.
How automatic limits decide what to keep
Microsoft documents the algorithm explicitly [4]:
| Version age | What is retained |
|---|---|
| First 30 days | All versions, within the 500-version count limit |
| 30–60 days | Hourly versions (the version created at the top of each hour) |
| 60–180 days | Daily versions (the version created at the start of each day) |
| Beyond 180 days | Weekly versions, kept indefinitely until the 500-version cap is reached |
Two limits still apply on top of that. The 500-version ceiling remains, and the behaviour is built around files edited in place — Tony Redmond of Practical 365 notes: “Intelligent versioning works for files created by Office applications. It doesn’t support file types like PDF where completely new versions of files are uploaded to SharePoint to update a file in a library.” [6] Plan separately for PDFs and other formats that are replaced rather than edited.
Setting Expiration and Limits for Versions
Microsoft documents exactly three version storage modes [4]:
- Automatic (Microsoft’s recommendation)
SharePoint thins versions by age on the schedule above. No count or age estimate needed from admins, and key restore points survive even on files nobody has edited recently. - Manual, with a major version limit and an expiration period
Versions are deleted once they exceed either the count or the age. Lowest storage impact — but on a file with no recent edits, all its versions can eventually be trimmed. - Manual, with a major version limit and no expiration
The configured count is always kept regardless of age. The most predictable option, and the one most likely to consume storage if you have heavily edited files or set the limit high.
For instance, legal agreements may need complete version histories for years, while project files might only need milestone versions for shorter periods. Note the compliance carve-out: files under a retention policy or an eDiscovery hold ignore versioning limits entirely until the hold is released, and versions of documents marked as records can’t be deleted at all [5].
Best Practices for Managing Version History
Creating Versioning Policies
To manage document versions effectively in SharePoint libraries, teams need clear and well-documented policies. These guidelines should strike a balance between keeping documents accessible and managing storage efficiently.
A solid versioning policy should cover:
- Approval processes : Define workflows and required approvers for major versions.
- Roles and responsibilities : Assign specific tasks for version management.
- Document categories : Outline requirements for different types of documents.
- Implementation steps : Provide instructions for handling various content types.
Once these policies are in place, the focus shifts to optimizing storage to handle version history effectively.
Optimizing Storage for Versions
Managing storage requires a thoughtful approach to version history. SharePoint’s built-in versioning features can help retain important document history while minimizing storage usage.
Retention rules can be customized based on document type and organizational needs:
- Project Files : Retain for 6 months if actively used.
- Legal Documents : Keep longer to meet compliance requirements.
- Standard Files : Use a 12-month retention period for general documents.
“Intelligent versioning works for files created by Office applications. It doesn’t support file types like PDF where completely new versions of files are uploaded to SharePoint to update a file in a library.” – Tony Redmond, Practical 365 [6]
This limitation means organizations need a separate plan for managing versions of PDFs and similar file types. For everything else, automatic limits keep recent versions in full and thin out older ones on the schedule above, which cuts storage without removing the restore points people actually reach for.
Regular audits are essential to ensure these storage strategies remain effective and compliant.
Conducting Regular Audits
Auditing version history regularly ensures compliance and supports strong governance. These reviews help organizations spot potential issues early and stay aligned with regulatory standards.
Key areas to review during audits include:
- Version Distribution : Check the number of versions stored across libraries.
- Storage Impact : Monitor how version history affects storage quotas.
- Policy Adherence : Ensure retention and versioning rules are followed.
- Access Trends : Analyze how often versions are restored or viewed.
Aim to conduct quarterly reviews of version history metrics. Use SharePoint’s admin center to generate detailed reports on version distribution and storage usage. Adjust policies based on audit findings to maintain effective version management and compliance with governance requirements.
Where nBold fits

Version history is a SharePoint setting — nBold doesn’t manage it, and no third-party tool needs to. What nBold does is one step earlier: it provisions Microsoft Teams workspaces and their SharePoint sites from approved workspace templates, so every new workspace starts with the same document library structure, naming convention, permissions and governance policies instead of being assembled by hand.
That matters for versioning in a practical way: version history limits are set per library (or inherited from the site), so consistent, template-provisioned sites are far easier to apply a single retention standard to than a sprawl of ad-hoc teams each configured differently.
Summary and Final Thoughts
Recommendations for Better Version Control
To get the most out of SharePoint’s version control, try these strategies:
- Smart Storage Management : Adjust version limits instead of sticking with the 500-version default. Microsoft’s own figure for switching to automatic limits is roughly a 96% reduction in version storage over six months compared with count limits alone [4] — run a “what-if” report first to see what it would trim in your tenant.
- Clear Compliance Policies : Set up versioning rules that match your data management regulations. Focus on retention policies that meet both your business goals and legal requirements.
- Standardize the libraries first : version limits are applied per library or inherited from the site, so the fewer ad-hoc, hand-built sites you have, the fewer exceptions you end up managing. Provisioning workspaces from approved templates keeps library structure and governance consistent enough to apply one retention standard across them.
Key Features of SharePoint Version History
SharePoint’s version history is a cornerstone of document management. Using these features effectively can bring even greater benefits:
| Feature | Functionality | Business Benefit |
|---|---|---|
| Automatic version history limits | Thins versions by age: all in the first 30 days, then hourly, daily, weekly | ~96% less version storage over six months vs count limits [4] |
| Manual version limits | 500 major versions by default; configurable 100–50,000, optionally with an expiration period | Predictable, auditable retention per library |
| Purview audit events | Log limit changes, trim jobs and version deletions | Evidence for audit and compliance reviews [5] |
To maximize these features, consider these best practices:
- Manage Document Lifecycles : Use retention policies to automatically handle older versions in line with your business needs.
- Track Changes Clearly : Require team members to add detailed comments for major updates. This helps with compliance and makes audits easier.
- Regular Maintenance : Review your version settings every quarter to ensure they still align with your storage and business goals.
FAQs
How many versions does SharePoint keep by default?
The default organization version history limit in SharePoint Online is a manual limit of 500 major versions per file with no expiration. That default applies to every new document library unless an admin or site owner overrides it [1].
What is the maximum number of versions in SharePoint?
You can configure up to 50,000 major versions per file (the admin center accepts 100–50,000). Minor versions are capped separately at 511 minor versions per major version, and that cap can’t be changed — attempting to save beyond it overwrites the most recent minor version [2].
Do SharePoint versions count against my storage quota?
Yes. Each retained version is stored as a full copy of the file, which is why version history is one of the main drivers of SharePoint storage growth [3]. Switching to automatic version history limits is Microsoft’s recommended way to shrink that footprint while keeping recent restore points [4].
Can I recover a version that a version limit deleted?
No. Versions trimmed because they exceeded a library’s limit — or removed by a scheduled trim job — bypass the recycle bin and can’t be recovered. Only versions a user deletes by hand from a file’s version history go to the site recycle bin [5].
Why is Version History greyed out or missing on a file?
Versioning is on by default in SharePoint document libraries [2], so a missing or greyed-out Version history command normally means versioning was turned off on that library or its version count was set to zero. Check the library’s versioning settings first; if content approval is enabled, draft item security can also hide minor versions from users with read-only access.
Can SharePoint be used for version control?
Yes, SharePoint provides robust tools for version control, making it ideal for collaborative work. It tracks changes automatically with features like autosave and co-authoring, which allows multiple users to edit a document at the same time.
Here are some key features of SharePoint’s version control system:
| Feature | Description |
|---|---|
| Automatic version history limits | Thin versions out by age so recent restore points stay intact while storage use drops. |
| Co-authoring | Lets multiple users edit a document simultaneously, with every change tracked in real time. |
| Automatic Version Creation | Saves a detailed history of changes whenever a document is updated. |
These features make SharePoint particularly effective in team-oriented and enterprise settings.