The 500-version default: why every SharePoint library is quietly hoarding storage
Every SharePoint document library ships with major versioning on and a cap of 500 versions per file. On a 250 MB InDesign file that is 125 GB per file. Here is where the storage actually goes, and what to change without breaking anyone's workflow.
Open any document library in your tenant, click into Library Settings → Versioning settings, and you will find the same two defaults Microsoft has been shipping for a decade: major versioning is on, and the limit is 500 versions per file. Most admins never touch this screen. The result is the biggest silent storage tax in Microsoft 365.
The maths
Take a 250 MB InDesign packaging file the design team saves twice a day for a year:
- 250 MB × 2 saves/day × 250 working days = 500 saves.
- The 500-version cap kicks in and starts pruning the oldest — so you are always at 500 stored versions.
- 500 × 250 MB = 125 GB. For one file.
- The current version is 250 MB. Reclaimable if you kept only the current: 124.75 GB.
Multiply by every large binary in the tenant — Illustrator files, video assets, CAD drawings, PSTs, ISO images — and the reclaim across a design-heavy department can be 30-60% of that team's SharePoint quota.
Why the default exists
Version history is a genuinely useful feature. "Restore previous version" has saved a lot of Monday mornings. The 500-version default exists because Microsoft cannot know your risk appetite in advance — so they chose an aggressively safe number. That number is right for a 5 MB Word document. It is dangerously wrong for anything measured in hundreds of megabytes.
What to change
The right settings depend on the type of content in the library. A pragmatic starting policy:
- General document libraries (Word / Excel / PPT under 20 MB): cap at 50 major versions. Rare that anyone reaches for version 47.
- Design / video / CAD libraries (files over 100 MB): cap at 10-20 major versions and rely on Microsoft 365 Backup or a source-control tool for anything longer.
- Contracts, policies, HR records: cap at 100 but combine with a retention label — the audit trail matters more than the historical bytes.
- System / integration libraries (populated by a bot or a Power Automate flow): cap at 5-10 and disable minor versioning entirely.
Doing the reclaim safely
Changing the cap only affects NEW versions. Existing history stays until you actively prune it. Two options:
- Wait it out — every new save trims the tail to the new cap. Predictable, no surprises, no user complaints. Takes weeks-to-months on active libraries.
- Bulk-prune — a PowerShell / Graph script that reads the current version list per file and deletes older versions server-side. Fast, but do it after hours with a rollback plan.
How TSO surfaces this
The File Versions tab on any scan detail page walks every drive above your chosen size threshold, calls Graph /versions per file, and reports the top-N by reclaimable bytes. The reclaim column is (versions − 1) × current file size. Hover the version count to see the per-file estimate; the footer row sums across the visible rows so you can quote one number to the data owner.