Image files are among the largest individual storage consumers in SharePoint Online, and each replacement creates a full-copy version in any library that has versioning enabled. Three approaches exist to reduce that footprint - they differ sharply in effort, risk, and scale.
| Approach | Admin effort | Metadata preserved | Works at scale | Breaks existing links |
|---|---|---|---|---|
| Manual compression | Very high | No | No | Yes |
| PowerShell scripting | High | Partially | With significant effort | Depends on implementation |
| ShareMaster Image Reducer | Low | Yes | Yes | No |
Why image storage in SharePoint Online grows faster than expected
Unlike Office documents, where SharePoint stores binary diffs between versions, image files are stored as full copies on every version. A 5 MB marketing photo replaced twelve times occupies 65 MB total - 60 MB in version history plus the current file. Across a shared library with hundreds of product images, that compounds into gigabytes before anyone notices.
The Microsoft 365 admin center shows total storage per site but does not break that figure down by file type or distinguish current content from version history. The result is that image-driven storage growth tends to be invisible until a site approaches its quota limit. For a full picture of what the storage limits look like at the tenant level, see the Microsoft 365 plan storage quota reference.
Option 1: Manual compression (download, compress, re-upload)
The most obvious approach: download each oversized image to a local machine, run it through a compression tool such as Squoosh, TinyPNG, or an image editor, then re-upload to SharePoint.
The problems compound quickly at any meaningful scale. Re-uploading a file in SharePoint creates a new item with a new internal ID. Any shared link that pointed to the old file stops resolving. Links embedded in other SharePoint pages or documents break because SharePoint's link resolution uses the file's unique item ID, not just its path. The re-uploaded file also starts a clean version history: all previous versions are lost.
For fewer than 30 images in a library with no active sharing links, manual compression is acceptable. For a library with hundreds of images where shared links are in active use - for example, product images embedded in published intranet pages - it is the worst available option. The person doing the work must also accurately identify which images need compressing, compress them without introducing visible quality loss, and re-upload to exactly the right location without error. One wrong upload leaves a gap or a duplicate that is difficult to detect until a user reports a broken image.
Option 2: PowerShell scripting with PnP PowerShell
PnP PowerShell can connect to SharePoint Online, enumerate image files above a threshold size, download them, invoke an image processing library, and re-upload. A well-written script can read custom metadata column values before download and write them back afterward using Set-PnPListItem, and can restore the original modified-by and modified-date stamps to preserve the file's audit trail. This addresses the metadata loss problem that makes manual compression impractical for governed libraries.
The effort required to build this safely is substantial. The script must handle SharePoint Online throttling, which will rate-limit any tool that sends too many requests in a short period. Graceful resumption from failures is also required - a half-processed library is harder to recover than one that was never started. Logging is essential: what was processed, what was skipped, and why. Checked-out files, locked items, and libraries with unique permissions all need explicit handling. And the whole thing must be tested against a non-production copy before being run against any library that contains real content.
For context on the throttling constraints that any scripting solution must respect, see the SharePoint throttling limits reference. A script that ignores throttling will generate HTTP 429 errors and partial results, which are worse than no results at all.
PowerShell is the right choice for organizations with a dedicated scripting team, no budget for third-party tooling, and several weeks available for development and validation. It is a poor fit for admins who need results within days or who do not have the PowerShell depth to build and test a file-processing pipeline safely.
Option 3: ShareMaster Space Master Image Reducer
ShareMaster's Space Master includes an Image Reducer that connects to SharePoint Online and compresses image files across libraries without a download-re-upload cycle. Because the compression operates in place, existing shared links remain valid and metadata is preserved. Version history and permissions are unaffected.
The tool works across multiple sites in a single configured operation, making it practical for tenants with dozens of libraries containing image content. No PowerShell authoring is required. There is no risk of uploading a file to the wrong location or losing embedded links.
Image compression and version trimming are most effective when applied together. Images that have been replaced several times carry full-copy versions in version history; compressing the current image while trimming old versions produces the maximum storage recovery. The version history trimming guide covers how to approach the trimming side of that workflow with Space Master's Version Trimmer.
Explore Space Master including the Image Reducer →
What is the easiest way to reduce image storage in SharePoint Online?
For most teams, ShareMaster's Image Reducer is the lowest-effort path to meaningful image storage savings. It requires no scripting, preserves existing shared links and metadata, and works across multiple sites in one operation. Manual compression works for very small libraries with no active sharing links. PowerShell scripting scales well but demands significant development investment to implement safely.
Decision matrix
| Your situation | Recommended approach |
|---|---|
| Fewer than 30 images, no active sharing links, no embedded references to the files | Manual compression |
| Large library, dedicated scripting team available, weeks available for development and testing | PnP PowerShell scripting |
| Multiple sites, shared links in active use, results needed within days | ShareMaster Image Reducer |
| Approaching storage quota, images and version history both contributing | ShareMaster Image Reducer combined with Version Trimmer |
Frequently Asked Questions
Does SharePoint Online automatically compress images?
SharePoint Online does not automatically compress or resize images uploaded to document libraries. It generates scaled thumbnails for preview display, but the original file stored in the library retains its full resolution and size. Admins who want to reduce image storage must either compress files before upload or use a dedicated tool.
How do I find large image files in SharePoint Online?
The SharePoint admin center shows storage per site but does not list individual file sizes or break down storage by file type. To find large images, use PnP PowerShell to query libraries filtered by extension and file size, or export a file inventory using Report Master to Excel and sort by file size to locate the largest image files across the tenant.
Do images in SharePoint Online accumulate version history?
Yes. If versioning is enabled on a library (the default for new document libraries), every time an image is replaced SharePoint stores the previous version as a complete copy. A 10 MB image replaced ten times produces 100 MB of version history in addition to the current file. Trimming old image versions is often as impactful as compressing current images, and both together produce the largest possible savings.