Does WordPress compress images when you upload them?

What happens to one upload

Upload a 4000 by 3000 pixel photo called harbour.jpg and WordPress writes a set of files to the uploads folder:

The theme and plugins may register further sizes, and each adds another file.

Three rules produce this. First, any image whose width or height exceeds the big image threshold of 2560 pixels is scaled down to fit, and that -scaled file is what WordPress uses wherever the full size is requested. The original stays on disk but is not linked from your pages. Second, each registered size smaller than the image is generated. Third, every generated file, including the scaled one, is saved with the editor's default quality: 82 for JPEG, 86 for WebP.

An image under 2560 pixels gets no -scaled copy, so its full size is your original file, at whatever compression you exported it with.

What core does not do

• It does not optimise the original. A 9 MB JPEG straight from a camera, if it is under 2560 pixels on both sides, is served at 9 MB wherever the full size is used.
• It does not convert formats by default, with one exception: HEIC photos from phones are converted to JPEG, since browsers cannot display HEIC. JPEGs stay JPEG and PNGs stay PNG. WebP and AVIF uploads are accepted and resized where the server's image library supports them, but core does not create WebP versions of your JPEGs.
• It does not compress PNGs the way it does JPEGs. PNG is lossless, so the resized copies are smaller only because they have fewer pixels. A large PNG photograph stays heavy at every size.
• It does not re-process existing files when you change settings. Sizes are made at upload.

So "WordPress compresses images" is true of the copies it makes and false of what you gave it.

Why this matters for SEO

Image weight is usually the largest part of a page's download, and the main image is often the Largest Contentful Paint element that Core Web Vitals measure. Two WordPress behaviours help: generated sizes are offered to browsers through srcset, so a phone gets a smaller file, and images below the top of the page are lazy-loaded.

Both depend on the sizes being reasonable in the first place. The cases that still go wrong:

• Heavy originals under the threshold used at full size, typically a 2400 pixel hero image exported at maximum quality.
• PNGs used for photographs.
• Images inserted at "Full size" when the column is 800 pixels wide.

None of this affects whether an image is indexed. It affects how fast the page is, which is the SEO-relevant part. Our guide to improving Core Web Vitals covers finding the LCP image.

Getting good results

Before upload

1. Resize to the largest size you will display, usually 1600 to 2000 pixels wide for full-width images.
2. Export photos as JPEG or WebP at quality 75 to 85, and use PNG only for graphics with flat colour or transparency.
3. Give the file a descriptive name.

In WordPress

4. Insert images at the size that fits the layout (Large is enough for most content columns) and let srcset handle the rest.
5. Leave the 2560 threshold alone unless you publish photography that needs more. Developers can change or disable it with the big_image_size_threshold filter, and change quality with wp_editor_set_quality:

add_filter( 'wp_editor_set_quality', function ( $quality, $mime_type ) {
    return 'image/jpeg' === $mime_type ? 78 : $quality;
}, 10, 2 );

6. After changing quality or registering new sizes, regenerate existing images with WP-CLI: wp media regenerate --yes. Only then do old uploads pick up the change.

Beyond core

7. An image optimisation plugin or a CDN with image processing can recompress originals and serve WebP or AVIF versions automatically. That is the piece core leaves to you.

To check a page, open the browser's developer tools, reload with the Network panel filtered to images, and sort by size. Anything over a few hundred kilobytes deserves a look.