How to Compress Images for WordPress

WordPress stores the full-resolution version of every image you upload. Post-upload compression plugins can shrink stored files after the fact, but the original large source usually remains on your server. The more efficient approach is to compress images to under 200KB before uploading. That keeps the media library lean from the start.

The issue compounds with scale. A site that's been publishing for three years with an average of 4 images per post, 2 posts per week, has uploaded roughly 1,250 images. If each one was 3MB uncompressed, that's 3.75GB of raw image data — before WordPress generates its additional size variants.

What WordPress Does With Every Image You Upload

When you upload a 5MB photo, WordPress doesn't store just that one file. It generates multiple size variants and stores each one as a separate file. The default set includes:

Thumbnail: 150×150px (cropped)
Medium: maximum 300×300px
Medium Large: 768px wide
Large: maximum 1,024px wide
The original full-size file

Themes and plugins add to this list. A typical commerce theme registers 3-5 additional sizes for product images. A page builder installation can add 2-3 more. A site running a full-featured theme with commerce and builder plugins can generate 8-12 size variants per upload.

A single 5MB upload can generate 20-40MB of stored files once all variants are created. Compress that image to 300KB before uploading, and the same generation process produces 2-3MB of stored files. The difference is 18-38MB per image upload, compounded across every image on your site.

Why Pre-Upload Compression Works Better

Post-upload compression tools improve existing media libraries, but they operate after WordPress has already stored the large source file and generated variants. Pre-upload compression fixes the problem earlier in the workflow:

Your source file is already small. WordPress generates thumbnails and responsive variants from the compressed image, so every derivative starts from a leaner source.

The workflow scales predictably. There are no monthly processing caps to track for new uploads. Every image follows the same resize, compress, check, upload sequence.

Your media library stays cleaner. You avoid storing both a large original and a compressed derivative for the same image.

Sensitive images stay local until publication. Unreleased product photos, confidential screenshots, and client work under NDA can be compressed in the browser before you decide where to publish them.

The Better Workflow: Compress Before You Upload

Compress images on your machine, then upload the already-compressed version. WordPress generates all its size variants from the compressed source, so every variant inherits the smaller file size.

The workflow:

Get the image from your camera, stock photo service, or designer
Resize to the maximum display width you need (more on this below)
Compress to under 200KB for body images, under 300KB for featured images
Run a quick visual check at 100% zoom
Upload to WordPress

The Image Optimizer for WordPress uploads runs in your browser. Nothing is uploaded to any server — you compress locally, then take the output file and upload it to WordPress yourself. This is the difference between compressing before the file leaves your machine and compressing after it's already stored on a third-party server.

Specific File Size Targets for WordPress

These targets apply to the file you upload to WordPress before WordPress resizes it:

Featured images (post header/hero): under 300KB, with 150-200KB as the target. WordPress will generate a medium and thumbnail variant from this, but those sizes matter less — the full-featured image is what appears at the top of your post and is what Google measures for Largest Contentful Paint.

Body images in posts: under 150KB. Images embedded in post content typically display at 700-800px wide in standard themes. Size to that dimension before compressing.

WooCommerce product images: under 200KB for the main product image, under 100KB for gallery thumbnails. WooCommerce generates several product image sizes; the main image (typically displayed at 600-800px) is the one most users see first.

Author avatars and small UI images: under 30KB. These display at 48-96px. Any larger and you're storing data that's scaled away immediately.

Resize First, Then Compress

A 4,000×3,000px image from a DSLR or modern smartphone is usually 5-10x wider than it needs to be for web display. Compressing that image without resizing first leaves most of that redundancy in place.

For most WordPress themes, blog content columns are 700-900px wide. A featured image can display at 1,200px wide on a large screen. To cover retina displays, resize to 1,600px wide for featured images and 1,200px for body images. These dimensions cover 2x retina rendering while being half the resolution of a typical camera output.

After resizing, compress. At WebP quality 80% or JPEG quality 75-80%, a 1,600px-wide photo usually lands between 100-300KB based on subject complexity. That is the range you want.

WordPress and WebP Format

WordPress added native WebP support in version 5.8, released July 2021. If you're running WordPress 5.8 or later (check Dashboard > Updates), you can upload WebP files directly. WordPress will generate WebP variants for all registered image sizes.

The prerequisite is that your server has the GD or Imagick library compiled with WebP support. Most managed WordPress hosts have this configured. Shared hosting varies. To check: go to Tools > Site Health > Info > Media Handling in your WordPress dashboard. If it shows "WebP generation: Supported," you are set.

WebP saves 25-35% over JPEG at equivalent perceived quality. For a site with 1,000 images, switching from JPEG to WebP is equivalent to eliminating 250-350 images' worth of data from your server and from your users' download queues.

Core Web Vitals and Your Featured Image

Google's Largest Contentful Paint (LCP) measures the time from page start until the largest visible element is rendered. For most WordPress blog posts and product pages, the largest element is the featured image at the top.

An unoptimized 2MB featured image on a typical 4G mobile connection (10Mbps average) takes 1.6 seconds to download. Add server response time, DNS lookup, and rendering overhead, and you're looking at an LCP of 4-7 seconds. Google's "good" threshold is 2.5 seconds.

Compressing the featured image to 200KB on the same connection: 0.16 seconds download time. That alone can push your LCP from failing to passing. Server response time, render-blocking scripts, and caching all matter, but the featured image is the most common culprit and the easiest to fix.

Check your current LCP score at PageSpeed Insights (pagespeed.web.dev). Enter your URL and look at the "Opportunities" section. If it lists "Properly size images" or "Serve images in next-gen formats," those are your featured and body images.

The Regenerate Thumbnails Plugin

After you switch themes or change image dimensions in your theme settings, WordPress doesn't automatically regenerate existing image variants. Your existing posts will use the old-sized thumbnails until you regenerate them.

The "Regenerate Thumbnails" plugin (it's free, in the WordPress plugin directory) reruns the size generation for all existing images using the current registered sizes. Run it after major theme changes or if you add a new page builder that registers additional image sizes.

This doesn't change the source files — it just regenerates the variants WordPress creates from the source. If your sources were compressed before upload, the regenerated variants are also compressed.

Edge Case: Page Builders Loading Full-Size Images

This catches people regularly. Page builders can load the full-resolution version of an image regardless of the display size. You can compress an image to 200KB, upload it, and the page builder will load the 200KB version as intended when its image handling settings respect WordPress defaults.

Check the builder's performance settings and make sure lazy loading and responsive image selection are enabled. These settings control whether the builder defers below-fold images and whether it respects WordPress's responsive image size selection.

If you are seeing full-size images loaded in a page builder layout even after optimizing the source files, the builder is overriding WordPress's size selection. Enable the responsive images setting in the builder's configuration to fix it.

Putting It Together

The sustainable workflow is simple: compress before upload, check file sizes against the targets above, and use WebP if your server supports it. This creates no ongoing plugin dependency, keeps your images on your machine until you're ready to publish them, and results in a leaner media library from the start.

Retroactively fixing an existing library means replacing files through the media library's "Upload a new file" option or via FTP — time-consuming but doable if site speed is a meaningful priority. For most active WordPress sites, the higher-leverage step is getting the pre-upload workflow right going forward and not adding to the existing problem.

The Image Optimizer for WordPress uploads is the fastest way to go from a raw image to something upload-ready. Drag the file in, set the format and quality, save the result, upload to WordPress. The whole process takes under a minute per image.