A SharePoint site showing 400 GB used tells you almost nothing about where to start. Without a per-library storage breakdown, every cleanup decision is guesswork: you are equally likely to spend an hour on a library that contributes 2 GB as one that holds 180 GB of accumulated version history.
This guide walks through how to generate a per-library storage report for SharePoint Online, interpret the results, and prioritise which libraries to act on first.
What does a per-library SharePoint storage report show?
A per-library storage report breaks a site collection's total quota consumption into individual rows, one per document library or list. Each row shows the total storage that library occupies, split into current file size and version history storage. That split is the key insight: a library's current files might occupy 8 GB while its version history consumes a further 65 GB. Without this breakdown, the 65 GB is invisible inside the site's total number and there is no obvious starting point for cleanup.
Why site-level totals are not enough
The SharePoint admin center shows total storage per site collection. That number includes current files, version history, recycle bin contents, and metadata. It does not separate these components or break them down by library. As a result, a site sitting at 95% of its quota could be in that state for very different reasons: a handful of large video files uploaded to a single library, version history spread across dozens of smaller libraries, or a recently emptied recycle bin that has not yet cleared from the quota counter.
Each of those situations calls for a different response. A site-level total sends you into each library manually to investigate. A per-library report with version history broken out takes you directly to the right library and tells you which cleanup action to apply.
How to generate a SharePoint storage report by library using Report Master
Step 1: Connect with a SharePoint Administrator account
Open ShareMaster and sign in using an account that holds the SharePoint Administrator role in your Microsoft 365 tenant. This role is required to enumerate storage data across site collections you are not personally a member of. The Global Administrator role also works but is more privilege than necessary for reporting.
Step 2: Select the storage utilisation report in Report Master
Navigate to Report Master and select the storage utilisation report type. Set the target scope: a single site collection gives you a library-by-library breakdown for that site; a multi-site run gives you a cross-tenant view where each row represents a library across all sites in scope.
For an initial audit, running across the full tenant surfaces the highest-impact libraries regardless of which site they live in. You can always narrow the scope once you know which sites to focus on.
Step 3: Run the report and export to Excel
Run the storage report. Report Master reads the SharePoint API to collect per-library data including total library size, current content size, and version history size. The time to complete scales with the number of libraries in scope; a tenant with 200 sites and an average of 10 libraries per site will typically complete in a few minutes.
When the report finishes, export to Excel. The export includes all columns with auto-filters applied so you can sort and filter immediately without reformatting.
See what Report Master exports
Step 4: Sort and prioritise
In Excel, sort the Version History Storage column from largest to smallest. The libraries at the top of that list are your primary targets: they hold the most accumulated historical data and will yield the largest storage reclaim per cleanup action. Cross-reference with file type: libraries containing PDFs, images, or video files store full copies of every version, so they accumulate storage faster than Office document libraries.
Reading the results: what the columns mean
| Column | What it means | What to look for |
|---|---|---|
| Total library size | All storage consumed by this library: current files, versions, recycle bin, metadata | Libraries over 10 GB are worth investigating; over 50 GB are immediate priorities |
| Current file size | Storage consumed by the latest version of each file only | The baseline: what the library would consume if version history were cleared entirely |
| Version history size | Storage consumed by all non-current versions | The gap between this and current file size is the reclaimable storage from trimming |
| File count | Number of items in the library (current versions only) | High file count with large version history indicates many files each carrying many versions |
| Average versions per file | Version count averaged across all files in the library | Averages above 50 suggest the library's version limit policy was never lowered from the default of 500 |
What to do with high-storage libraries
Version history dominates: apply a version trim
When a library's version history is significantly larger than its current file size, a version trim is the correct first action. Use Space Master's Version Trimmer to set a keep policy for that library: for example, retain the last 20 versions per file and delete any version older than 180 days beyond those 20. Running this policy across a library where files carry an average of 200 versions each will typically reclaim 80 to 90% of the version history storage with no loss of current content.
For a detailed walkthrough of version trimming, see the guide to trimming SharePoint version history.
Current file size dominates: look at the files themselves
If a library's current file size is the dominant number rather than its version history, the storage is in the files themselves. This is where file-type matters: a library full of raw image files, uncompressed CAD exports, or large video files can legitimately consume hundreds of gigabytes in current content alone. Options here include moving large media to a dedicated storage location, using Space Master's Image Reducer to compress oversized images in-place, or archiving files that are no longer actively referenced.
Run before any migration
A per-library storage report run before a cross-tenant or same-tenant migration tells you the exact data volume you are migrating, separated by library. Libraries with large version history that you plan to migrate with full version preservation will dramatically inflate the migration data volume. Identifying them in advance lets you choose which libraries to trim first, reducing migration time and destination quota consumption from day one.
Frequently Asked Questions
Can the SharePoint admin center show storage broken down by library?
The SharePoint admin center shows storage per site collection only. It does not break that number down to the library level. To see library-level storage detail including the version history split, you need either PowerShell scripting or Report Master's storage utilisation report.
What is version history storage in a SharePoint library report?
Version history storage is the quota consumed by historical versions of files, separate from the current version's size. A library where current files total 10 GB but total library size is 85 GB has 75 GB in version history. Identifying this split is the prerequisite for targeted cleanup.
Which libraries should I target first when cleaning up SharePoint storage?
Prioritise libraries where version history storage is large relative to current file size. A ratio of 5:1 or higher indicates a library where a version trim will reclaim significant quota with minimal risk. Also target libraries containing PDFs, images, or video files, since these file types store a full copy per version rather than a binary diff.
Does SharePoint storage include items in the recycle bin?
Yes. Items in the first-stage and second-stage recycle bins count toward the site collection storage quota. If a library's reported storage seems higher than the file inventory explains, check whether a large number of recently deleted items are sitting in the recycle bin. Clearing the recycle bin reclaims that quota immediately, without any action on the library's current files or version history.