Your SharePoint site storage report says 80 GB used. What it does not say is which files have accumulated hundreds of versions, or where a targeted trim would reclaim the most quota. That answer comes from a version count export.
This guide covers how to export per-file version counts from SharePoint Online to Excel using Report Master, how to read the results, and how to act on them without trimming anything you still need.
What does a version count report show?
A version count report lists every file in the scope you define with the number of stored versions next to it. The key data points are the current version count, the version history storage that count represents, the file type, and the library it lives in.
This is different from a library-level storage report, which shows you total storage and average version counts per library. The version count export goes to the file level: you can see that a specific shared template has 487 versions while the rest of the library averages twelve, and you can target that file directly rather than trimming the whole library with a broad policy.
Why per-file counts matter more than library averages
Version distribution inside a SharePoint library is rarely uniform. The pattern that shows up most often in practice: a small number of heavily-used files (shared templates, frequently updated plans, master reference documents) accumulate version counts far above the library average, while the majority of files sit in single digits. A library average of 35 versions might mask one file at 490 and three hundred files at twelve.
Applying a library-wide trim policy based on an average misses this skew. Setting a keep-last-50 policy against a library where most files have under twenty versions leaves the real outlier untouched while deleting history from files that needed it. The file-level report reveals the distribution before you commit to a policy.
Version count matters most on large files. SharePoint counts every stored version against your quota at its full size, whatever the file type: there is no saving for Office documents. A 2 MB PDF with 200 versions occupies approximately 400 MB in version history. High version counts on large files are often the single largest source of reclaimable storage on a tenant.
How to export version counts from SharePoint using Report Master
Report Master is the Reports area of the ShareMaster app, and two of its reports cover this job between them. Neither writes anything to SharePoint.
Microsoft also has a native route: the New-SPOSiteFileVersionExpirationReportJob cmdlet queues a version storage report for a site and writes a CSV with one row per version into a document library, which you then group by file in Excel to get counts. See Microsoft's version usage report tutorial.
Step 1: Connect to the site
Open ShareMaster, go to Reports and connect to the site you want to measure, using an account that can read every library on it. The per-file reports below work one site at a time. If you first need to know which sites to look at, the Tenant Storage Metric report ranks libraries and the largest files across the whole tenant; that one needs the SharePoint Administrator role.
Step 2: Run the Version Trimming Report with nothing retained
Choose Version Trimming Report and tick the libraries to include. Leave Retain some versions? unticked and the other filters off. In this report-only mode nothing is deleted: the tool works out what a trim would remove and writes it to a CSV, and with nothing retained, "what it would remove" is every previous version of every file.
The CSV has one row per file with more than one version: the library, file path, file name, extension, the number of versions that would be removed, the space they use, and the current file size. Add one to the version column for the total count including the current version. A large library takes a while, because every file's version history has to be read.
Step 3: Add the Site Storage Metric workbook
Run Site Storage Metric on the same site. It writes an Excel workbook with a summary sheet per library (total size including versions, current file size, and the amount saved if trimmed), a sheet of the largest files ranked by size including versions, and a sheet per library that lists each file followed by a row for every stored version with its version number and size.
Open the CSV in Excel, turn on filters and sort the version column from highest to lowest to see the extreme outliers at the top, then sort by the space column to find files where high counts translate to high quota consumption.
See what else Report Master exports
Reading the version count export
| Column | What it tells you | What to look for |
|---|---|---|
| Number of versions removed | With nothing retained, the number of previous versions stored for this file | Files at 449 or more are close to the 500-version ceiling and may be losing their oldest history automatically |
| Space saved (KB) | Storage consumed by those previous versions (not including the current version) | Sort by this column to find the highest-cost files regardless of their version count |
| Extension | Extension of the file (.docx, .pdf, .jpg, .xlsx, etc.) | Large media and design files at high version counts are usually the most expensive rows |
| File size | Size of the current version in KB | Version count multiplied by file size is a quick estimate of what a file's history costs |
| List / file path | The library and the file's full path | Cluster your cleanup by library: it is more efficient to run the Version Trimmer against a whole library than file by file |
A practical approach: create two filtered views in Excel. The first filters for a version count above 100 and a current file size above 1 MB. These are files where every edit adds a sizeable copy to the history. The second filters for space used by versions above 1 GB regardless of count. These are the two groups where trimming delivers the highest return per action.
What to do after exporting: prioritising version cleanup
Once you have identified which files and libraries carry the highest version load, there are two levers to pull.
Trim existing versions. For libraries where current version counts are high, use Space Master's Version Trimmer to apply a keep policy: retain the last N versions per file and delete anything older. A keep-last-30 policy applied to a library where the average file has 250 versions of similar size will reclaim roughly 88% of the version history storage from that library. For the specific outliers you identified in the export, the trimmer's file name filter (with * as a wildcard) and folder selection let you target those files rather than the whole library. The trimmer deletes versions rather than recycling them, so run it in report mode first.
Set a lower version limit going forward. After trimming, set the library's version limit to a value that prevents the same accumulation from recurring. For most document libraries, keeping 30 to 50 major versions is sufficient. Use the guide to setting the SharePoint library version limit for the steps and recommended values by library type.
For a broader view of how version history fits into your overall storage picture, the guide to getting a SharePoint storage report by library covers the library-level storage breakdown that complements the per-file version count data.
Once you have trimmed the worst offenders, the guide to trimming SharePoint version history covers how to run Space Master's Version Trimmer across a site or tenant for systematic cleanup.
Frequently Asked Questions
What is the default version limit for SharePoint Online files?
SharePoint Online stores up to 500 versions per file by default. Once a file reaches that ceiling, each new version drops the oldest one. Files on high-traffic shared documents can reach 500 versions within months if no lower library limit has been set. Checking version counts regularly, and adjusting library limits after reviewing the data, prevents silent quota consumption from growing unnoticed.
Does a high version count always mean high storage consumption?
It depends on the file size. SharePoint counts every stored version against your quota at its full size, Office documents included, so many versions of a small file cost little and a few versions of a large one cost a lot. A 5 MB PDF at 200 versions consumes roughly 1 GB in version history regardless of how small the changes between versions were. Cross-referencing version count with the space column in the export reveals which high-count files are actually high-cost.
How do I reduce version counts after identifying high-version files?
Use Space Master's Version Trimmer against the libraries identified in the export, or the Bulk Version Trimmer across several sites. Set a keep policy (for example, keep the last 30 versions and delete anything older) and run it in report mode first, because the trimmer deletes versions rather than sending them to the recycle bin. The current file and the versions you chose to keep are not affected.