You have trimmed version history and deleted old files, but your SharePoint storage numbers barely moved. If that is your situation, images are the likely culprit. A single campaign library where users uploaded raw photos from a shared drive can hold fifty gigabytes of PNGs that display on screen at a fraction of their stored size. SharePoint Online stores every image at its original resolution with no automatic compression, and most tenants have no systematic way to know how much quota images consume until they look.
Why Images Drain SharePoint Storage More Than Expected
No server-side compression on upload
When a user uploads a 15 MB DSLR photo to a document library, SharePoint stores 15 MB on disk. It generates smaller thumbnail previews for the document card view, but those are supplementary files. The original sits at full resolution indefinitely. SharePoint Online does not apply any compression, downscaling, or format conversion at upload time.
This matters because the files users actually need are almost always much smaller than what they uploaded. A 4000 x 3000 pixel image displayed in a SharePoint news post header at 1200 pixels wide needs perhaps 300 KB, not 15 MB. The extra 14.7 MB is pure quota overhead.
Version history multiplies the problem
If versioning is enabled on an image library (which is the SharePoint default), every update to an image file creates a new historical version. Crop the photo slightly: two 15 MB versions. Upload a revised version for a rebranded header: three versions. An image library with 1,000 photos and an average of five versions per image is holding five times the storage of a single copy. Compressing those images alone recovers storage; compressing and then trimming the historical versions recovers substantially more.
Site Assets libraries and page images
Images embedded in SharePoint site pages - hero images, full-width section backgrounds, news thumbnails - are stored in the Site Assets library attached to each site. Admins rarely audit it directly. In tenants where the communications or intranet team publishes regularly, Site Assets grows continuously - a site with three years of news posts and page updates can accumulate several gigabytes of image files spread across hundreds of individual page assets.
How to Identify Image-Heavy Libraries Before You Compress
Compressing blindly across all libraries wastes time and risks changing files that are not worth targeting. A storage report first narrows your work to the libraries where images actually matter.
| Signal | What it suggests |
|---|---|
| Library storing more than 5 GB with fewer than 5,000 files | Average file size above 1 MB; almost certainly contains large images or video |
| Site Assets library consuming more than 500 MB | Heavy page publishing history; many full-resolution images stored for page canvases |
| Library with a high version count per file and image file types | Image files being edited and re-uploaded; pre-compression versions accumulating |
| Library name includes "photos", "media", "assets", "brand", "marketing" | High probability of raw or lightly-processed images from non-technical users |
Report Master exports a storage utilisation report to Excel with per-library file counts, total size, and last modified dates across all site collections. Sort by average file size descending to find libraries where a small number of large files are driving the storage total. That sorted list becomes your compression target list. For step-by-step guidance on building that report, see how to reduce SharePoint storage fast.
Step-by-Step: Compressing Images with Space Master
Space Master's Image Reducer processes JPEG and PNG files stored in SharePoint document libraries and rewrites them at a lower file size without changing the file name, the SharePoint metadata, or the URL. The compressed version becomes the new current version of the file; the original becomes a historical version that you can then trim.
- Open Space Master and connect to your tenant. Select the Image Reducer from the Space Master tool panel. The tool lists all sites in your tenant; select the sites containing the libraries you identified in the storage report.
- Select the target libraries. Expand the site tree and tick the libraries where image compression will make a measurable difference. You can select specific libraries rather than all libraries on a site, which lets you avoid compressing libraries where image fidelity is important (architectural drawings, medical imaging, product photography that requires print resolution).
- Set a target quality level. For SharePoint intranet content, a JPEG quality of 75 to 85 percent is visually indistinguishable on screen but typically reduces file size by 50 to 70 percent. For marketing assets used in printed materials, use 90 percent or higher. PNG files are converted to compressed PNGs; if lossless compression is insufficient, consider converting large PNGs to JPEG during the run.
- Assess which libraries are worth compressing. Not every library with image files will yield a meaningful saving. Use the storage report from Report Master to check the average file size across each target library before running. If the average is already under 500 KB, or the total image storage is under a few hundred megabytes, that library may not be worth including in the first run.
- Run the compression. Space Master processes files in batches, respecting SharePoint's API throttling limits to avoid interrupting active users. For large libraries, run the compression outside business hours.
- Trim the old versions after compression. Each compressed file now has a historical version containing the original. Use Space Master's Version Trimmer to remove versions older than a single day on the affected libraries. This removes the pre-compression originals and reclaims the full storage benefit. See how to trim SharePoint version history for the detailed process.
Typical Storage Recovery from Image Compression
Results vary significantly based on what was originally uploaded. Libraries built from phone photos or camera JPEGs at moderate resolution often see 40 to 60 percent size reduction. Libraries with raw files or high-resolution PNGs from a designer's workflow can see 70 to 85 percent reduction.
| Library type | Typical original size | Typical post-compression size | Saving at 80% JPEG quality |
|---|---|---|---|
| Marketing campaign photos (JPEG, camera uploads) | 50 GB | 12 - 18 GB | 65 - 75% |
| Site Assets (page hero images, news thumbnails) | 5 GB | 1 - 2 GB | 60 - 80% |
| Brand / logo library (PNG, high res) | 10 GB | 2 - 4 GB | 60 - 80% |
| Project documentation with embedded screenshots | 20 GB | 10 - 14 GB | 30 - 50% |
The combined saving from compression plus version trimming is typically larger than either step alone. A 15 MB image compressed to 3 MB with five historical versions goes from 75 MB of quota to 3 MB after both steps: a 96 percent reduction per file.
Frequently Asked Questions
Does SharePoint Online automatically compress images when they are uploaded?
No. SharePoint stores uploaded images at their original file size. Thumbnail previews are generated for display, but the stored original remains uncompressed. A 12 MB PNG stays at 12 MB in the library.
Do compressed images still look acceptable on SharePoint pages?
For most SharePoint use cases, yes. A JPEG at 80 percent quality is visually indistinguishable from the original on a standard monitor. Images used as news post thumbnails, section backgrounds, or card headers rarely need to be stored at camera resolution.
Will compressing images affect the version history for those files?
Yes, in a useful way. Compression creates a new current version; the original becomes a historical version. Trimming old versions after compression removes the pre-compression originals and reclaims the full storage benefit. Until you trim, both versions count against your quota.
How much storage can I realistically recover?
Libraries built from camera uploads or raw design files can shrink by 60 to 80 percent per file. A 50 GB photo library compressed at 80 percent JPEG quality may reach 12 to 18 GB. Combined with version trimming, the total saving per file can exceed 90 percent when multiple large historical versions existed before the compression run.