If you’ve ever deleted a handful of files in Microsoft 365 and seen your storage number drop drastically (or deleted hundreds of folders without noticing any impact at all), version history is usually why.
In SharePoint and OneDrive, a “file” is rarely just the single item you see on your screen. It’s usually a vertical stack: the current copy plus hundreds of possible saved versions created by autosave and co-authoring. In PowerPoint-heavy libraries, that hidden history can outweigh the visible file by ten times or more.
Lowering version is a smart way to slow future growth, but it won’t remove the backlog you’ve already accumulated. If you need storage to drop, you have to identify the version-heavy files, trim older versions safely, and understand the math behind how a single deck turns into a storage monster.
What version history is and why it drives storage
Version history is a record of saved states for a file. Instead of overwriting the previous copy, Microsoft 365 keeps older versions so you can restore work, compare changes, or recover from mistakes.
That’s a feature, not a bug. In SharePoint and OneDrive, versioning supports modern autosave and co-authoring, where files change constantly in small increments. However, it’s a common misconception that Microsoft only saves those “small increments.” In reality, for the purpose of your storage quota, Microsoft treats every major version as a full, independent copy of your file.
The storage catch is that “one file” is rarely just one file. It’s the current copy plus whatever version history is retained behind it. In libraries with frequent edits or long-lived working docs, that history can outweigh the visible file.
In practice, version sprawl comes from normal work patterns:
In a co-authored file, you’re not looking at one person saving occasionally. You’ve got multiple people editing, autosave capturing changes, and a steady stream of updates over days or weeks.
Even if the file never “feels” big, the history behind it grows in the background.
The worst offenders aren’t finished artifacts. They’re living documents that stay in use for months or years:
These files don’t get archived when a project ends because the work doesn’t really end. They just keep accumulating versions.
PowerPoint tends to combine the conditions above with one more factor: file size.
Decks bloat fast with images, embedded media, and copied slides, and small edits trigger saves constantly over a long lifespan. The result is a deck that looks like a single file in a library but behaves like a storage magnet once you include hundreds of versions.
When you realize that a single 50 MB deck with 200 versions is actually consuming 10 GB of your quota, the math starts to look very different.
Version history is hard to manage when it stays abstract, so here’s the simplest way to think about it:
Rule of thumb: file size × version count ≈ hidden footprint
In reality, versions vary in size and compression, so this won’t be exact, but it’s accurate enough to identify where version history is driving storage. And because Microsoft 365 counts each major version as a full copy against your quota, this is the most accurate way to find your storage drivers.
Consider a typical 25 MB marketing deck used for a weekly status update:
Suddenly, you aren’t dealing with a simple 25 MB file. You have 5 GB of storage tied up in one PowerPoint deck. Multiply that across a handful of similar decks, a long-running proposal, a tracker that’s been periodically updated for two years, and version history becomes a massive share of your total storage.
The point isn’t the exact number. It’s that the history behind the file can (and often does) outweigh the file you see.
Lowering version limits helps, but it can’t reduce what’s already there.
Version limits control how much history gets created going forward. If you reduce the number of versions retained, you reduce the rate at which version storage grows, especially in libraries where autosave and co-authoring are normal.
What limits don’t do is remove the backlog you already have. According to Microsoft’s guidance on versioning limits, even after you tighten settings, existing versions stay in place until they’re manually trimmed or naturally overwritten by new edits.
And even when you manually delete versions to free up space, they move to the site's recycle bin first, where they can remain for up to 93 days. That means your total "used storage" might not drop until those items officially age out of your environment.
If a file has accumulated hundreds of versions over months or years, changing the limit today changes what happens next, not what’s already stored.
If you need used storage to actually drop, you need a way to reduce existing version history in the places where it’s doing the most damage.
That’s version trimming. It’s a different lever than limits, and it’s the one that addresses what you’re already paying for.
You don’t need to audit the whole tenant to get value here. The goal is to find one or two libraries where version history is clearly doing outsized damage, then start trimming there.
Version sprawl tends to concentrate in the same few places:
To identify the specific culprits, you need to see the data SharePoint hides by default. There are two specific ways to do this:
The fastest way for a site owner to see the “depth” of a file’s history is to add a Version column to the standard library view.
Now, you can sort the library by file size and check the version count side-by-side. If you see a large PowerPoint with a version number like 450.0, you’ve found your storage driver.
If you want to see the total footprint of a library, including all hidden versions, use the Storage Metrics menu.
This page shows a Total Size column that includes the live file plus all of its version history. Navigating through this menu often reveals the hidden storage hog: a library that looks like it has 10 GB of files but is actually consuming 100 GB of your tenant’s quota.
Native views can help you find large files. What they don’t reliably show is how much of that size is version history versus the current file.
That gap is why teams either take a blunt approach (trim broadly, hope nothing breaks) or build one-off reporting with PowerShell to identify the true offenders.
Pick one library where the “small number of files, huge footprint” pattern is obvious. Use it as your first trimming candidate. Once you can show impact in one place, you can scale the same approach elsewhere without turning it into tenant-wide guesswork.
Version trimming works best as a controlled maintenance task, not a one-time purge. Run one tight pilot, prove impact, then turn it into a cadence.
Start with one library, not the whole tenant.
Tighten limits in that library so you’re not recreating the problem as you clean it up.
Keep it simple enough to explain to security, compliance, and the business.
Don’t trim until you’ve checked constraints that will create risk or pushback.
At minimum, confirm:
If you can’t get a clear answer, pick a different library for the first run.
Treat this like a change you’ll need to prove was worth it.
Also, expect timing lag: “used storage” doesn’t always reflect cleanup immediately, especially when deleted content remains retained. Deleted versions will sit in the site’s recycle bin for 93 days before the quota is actually credited back.
If trimming works once, the win is making it repeatable.
Microsoft gives you the levers: version limits, storage reporting, and the ability to manage versions at the file level. The hard part is doing anything with those levers in a real tenant.
While the process outline above works for a single high-impact library, attempting to repeat that process manually across hundreds or thousands of sites is literally impossible for a central IT team. Without a dedicated solution, you can’t scale the research, guardrail checks, and trimming commands across an entire organization.
Version Cleanup in Orchestry's Workspace Review.
Here’s how Orchestry turns an impossible manual task into a repeatable workflow:
If storage is creeping up even after you’ve tightened version limits, assume you’re still paying for historic version history.
Pick one high-usage library where a small number of files account for most of the footprint. Confirm guardrails, trim older versions, and measure what changed. Once you can do it safely in one place, you’ve got a playbook you can reuse.
Orchestry helps IT and workspace owners apply lifecycle and governance standards across Teams and SharePoint, improving visibility, reducing manual work, and lowering risk as AI makes content easier to discover.
To see Orchestry in action, request a demo or download our Features Sheet to learn more.