WordPress keeps several copies of every image, and optimizes none of them

Upload one photo to WordPress and you don’t get one file. You get a thumbnail, a medium, a medium-large, a large, the full size, and whatever extra sizes your theme and page builder registered. Six or eight files from one upload is normal. Every one is re-encoded at WordPress’s default JPEG quality and then never touched again.

Multiply that across a few years of posts and the uploads folder is usually the largest thing in your backup, and the slowest part of your pages. Most of that weight is avoidable.

Where the weight actually is

It’s the JPEGs. Photos dominate a typical library, and WordPress encodes them at a fixed quality (82 by default) with an old encoder. That is a reasonable safe default, not a small file. Screenshots and logos stored as PNG add more, because PNG is the wrong container for a lot of them.

There are two honest ways to cut this down, and they trade off differently.

1. Re-encode in place

Take each generated size and re-encode it to a smaller version of the same format: JPEG stays JPEG, WebP stays WebP. A modern encoder gets roughly a fifth to a quarter off a default WordPress JPEG with no visible change.

The appeal is that nothing else in your site notices. The filename, the dimensions and the extension are identical, so every URL keeps working, in every theme, in every cached page, in every hardcoded <img>. It is the boring, safe option, and for a lot of sites it is the right one.

What it will not do: change formats. A JPEG stays a JPEG, so you don’t get the bigger wins that a newer format would give you.

2. Serve next-gen formats

Generate an AVIF (and a WebP) next to each original and serve it through a <picture> tag, keeping the original JPEG or PNG as the fallback for older browsers. This is where the real savings are: at matched quality, AVIF needs far fewer bytes than JPEG, and it finally covers your PNGs too. We measured the gap across ~1,900 photos if you want the numbers.

The honest caveats, because there are some:

• It rewrites the page HTML, which makes it theme-independent, but it only touches <img> tags. A CSS background-image won’t be swapped.
• A JavaScript lazy-loader that rewrites src at runtime can miss it. Native loading="lazy" is fine.
• GIF isn’t covered yet.

The originals stay exactly where they are, so nothing is lost, and browsers that can’t read AVIF fall back to the file they already understood.

The part people actually worry about

Both approaches keep a backup of every original, so any image restores to its exact bytes with one click. A file is only ever replaced when the new one is strictly smaller, so nothing gets bigger. And if an optimization fails, it is skipped, not fatal: your upload never hangs and an image is never left half-written.

Doing it

This is what Patu Optimizer does. New uploads optimize automatically, a single bulk pass handles everything already in the library, and you pick in-place or next-gen per site. It runs on the Patu API, so the encoding happens off your server. A free key is enough to start.

Start with in-place if you want zero surprises. Reach for next-gen when you want the bytes and your pages use normal <img> tags. Either way, the goal is the same: stop shipping a media library that is two or three times heavier than it needs to be.