Every deleted file in SharePoint Online occupies storage quota for up to 186 days. That figure surprises most administrators the first time they hear it. The files are gone from the library. The folders are empty. But the storage gauge barely moves - because the recycle bin is holding the entire deleted dataset, and it counts against your tenant's pool just as much as active content does.
This is one of the most common sources of confusion during SharePoint storage audits. An admin runs a cleanup, deletes hundreds of gigabytes of redundant files, checks the storage report, and wonders why the numbers have not changed. The content did not disappear. It moved. Understanding this gap between "deleted" and "permanently removed" changes how you plan and execute storage management.
How SharePoint Storage Quota Works
SharePoint Online provides each Microsoft 365 organisation with a pooled storage quota: 1 TB plus 10 GB per Microsoft 365 licence, shared across all SharePoint site collections and OneDrive for Business accounts in the tenant. Every byte stored in SharePoint draws from this single pool - whether the content is in an active library, a version history entry, or sitting in the recycle bin waiting to expire.
First-stage and second-stage recycle bins
SharePoint Online operates a two-stage recycle bin system. When a user or admin deletes a file, it moves to the first-stage (end-user) recycle bin. Items remain there for up to 93 days, visible to the person who deleted them and to site administrators. During that window, anyone with sufficient access can restore the item.
After 93 days, or earlier if the first-stage recycle bin fills to 10% of the site collection's storage quota, items automatically move to the second-stage (site collection) recycle bin. Only site collection administrators and SharePoint administrators can see or restore items from there. The second stage holds items for another 93 days. After that, permanent deletion occurs and the storage is released.
In a worst case, a deleted file could hold storage for up to 186 days. See the full retention schedule on the SharePoint recycle bin retention reference page for specifics on how thresholds work across both stages.
What counts toward quota
Both recycle bin stages draw from the same tenant storage pool as active content. A 10GB file sitting in the second-stage recycle bin is just as "expensive" from a quota perspective as a 10GB file in a document library. The distinction is access: end users cannot see it, cannot interact with it, and will not notice it exists. From the storage pool's perspective, it is still there.
The implication is direct. If a tenant has consumed 95% of its SharePoint quota, and the admin deletes 50GB of content, the quota consumption figure will not change meaningfully for weeks - or months, depending on whether a manual recycle bin clear follows the deletion.
Why Admins Underestimate the Recycle Bin's Storage Impact
Three patterns explain most of the confusion.
The first is the assumption that "deleted" means "gone." On most consumer devices, emptying the recycle bin is a fast, final action. In SharePoint Online, the recycle bin is a retention layer, not a staging area for immediate deletion. Unless an administrator actively clears it, items stay for the full retention period.
The second pattern involves inherited tenants and site migrations. An administrator takes over a SharePoint environment that has been running for several years. The recycle bins across hundreds of site collections have never been systematically cleared. Years of accumulated deleted content - old project files, redundant backups, superseded policy documents - sits in the first and second stage, counted against the quota the organisation is paying for today.
The third: periodic mass deletions with no follow-up. Teams that run quarterly file cleanup projects delete large volumes of content, mark the task complete, and move on. Because no one clears the recycle bin, the expected storage reduction never materialises. The next storage audit shows numbers that contradict the cleanup log.
Version History Makes the Effect Larger
When a SharePoint file is deleted, its complete version history moves to the recycle bin along with the current version. For files that have been actively edited over months or years, this matters.
Consider a project proposal document edited by multiple contributors over a six-month period. Version history may have accumulated 120 versions. The current file is 3MB. Older versions average 2.5MB. The total storage footprint for that document - current version plus all tracked history - could exceed 300MB. When that single document is deleted, 300MB moves to the recycle bin, not 3MB.
This is why version history trimming should happen before a bulk delete - not after. Reducing a file's version count from 120 to 10 before deletion means 10 versions end up in the recycle bin rather than 120. The storage difference is significant at scale. The version history trimming guide covers the process using ShareMaster's Version Trimmer before a planned cleanup.
There is a counterpart situation too: administrators who trim version history from active files, then delete the files expecting a large storage recovery, are sometimes confused to find only partial recovery. This is because even a file with 10 remaining versions carries 10 units of version storage into the recycle bin. Full recovery comes only after the recycle bin is cleared.
How to See What Your Recycle Bin Is Actually Consuming
The SharePoint admin centre shows each site collection's total storage usage. There is no native line item that says "X GB is in the recycle bin." The recycle bin's contribution is folded into the site's overall figure. To isolate it, you need to compare storage before and after a clear.
The most direct method for a single site collection:
- Note the current total storage for the site in the SharePoint admin centre under Sites > Active Sites.
- Navigate to Site Settings > Site Collection Recycle Bin and clear both stages.
- Wait for the storage report to update (this can take several hours in large tenants).
- Note the storage figure again. The difference is what the recycle bin was holding.
For a tenant-wide view, this process needs to be repeated across every site collection, or you need a tool that aggregates storage data across sites. ShareMaster's Report Master exports a storage utilisation report by site collection, which lets you compare totals before and after a cleanup operation without navigating to each site individually.
Reducing Recycle Bin Storage Without Losing Recovery Options
The goal is not to eliminate the recycle bin's protective function. The retention window exists for good reasons: accidental deletions happen, files get deleted during sync conflicts, and the 93-day first-stage window has saved organisations from data loss more times than most admins want to count. What matters is clearing out content that has genuinely expired.
The most impactful action is a targeted clear rather than a blanket wipe. Review the recycle bin by date range. Items deleted more than 90 days ago are either recoverable from the second stage (and presumably not needed by now) or already past the first-stage window. Anything in the second stage that has been there for more than 60 days is unlikely to generate a recovery request. Those are the candidates for early permanent removal.
The second practical measure is establishing a regular review schedule. Quarterly reviews work for most organisations. During each review, clear content that is clearly past its recovery relevance: test site deletions, superseded document drafts from completed projects, temp files that were accidentally included in library deletes.
For organisations approaching their SharePoint storage quota, checking and clearing the recycle bin should come before purchasing additional storage. In many tenants, a full recycle bin clear releases 10-25% of apparent quota consumption. That is often enough to defer a quota purchase by one or two months while a longer-term storage strategy is developed.
The tenant-wide recycle bin clear guide walks through each step, including how to clear the second stage across all site collections. ShareMaster's Recycle Master handles the operation from a single connected session without PowerShell scripting against each site.
See how Recycle Master manages tenant-wide recycle bin search, clear, and restore
Frequently Asked Questions
Does the SharePoint recycle bin count toward storage quota?
Yes. Both the first-stage and second-stage SharePoint recycle bins draw from your organisation's SharePoint storage quota. Deleted items remain in the quota calculation until they are permanently removed, either through automatic expiry after up to 93 days per stage, or by an administrator clearing the recycle bin manually.
How long does SharePoint Online keep deleted items before permanently removing them?
SharePoint Online keeps deleted items in the first-stage recycle bin for 93 days, then moves them to the second stage for another 93 days. The maximum total retention is 186 days. If the first stage reaches 10% of the site collection quota, items are moved to the second stage earlier. An administrator can permanently delete items from either stage at any time.
How do I find out how much storage my SharePoint recycle bin is using?
The SharePoint admin centre does not display recycle bin storage separately. To measure it: record the site's total storage, clear the recycle bin, then check the storage figure again after the update propagates. The difference is the recycle bin's contribution. For a tenant-wide view, ShareMaster's Report Master exports storage data per site collection so you can compare before-and-after figures across your entire environment.