Optimize images for WordPress
This tool prepares images before they go into the media library: it brings them to at most 1600 pixels wide and looks for the smallest file that holds your quality target. This happens in your browser — there is no plugin, no service and no upload to anyone. What WordPress does with the file afterwards is up to WordPress; what goes in is a smaller source.
Drag an image here
or paste from the clipboard (Ctrl+V / ⌘V)
JPEG, PNG or WebP · the image stays on your device
Our own test series: 20 images against 1600 px width
11 of the 20 corpus images are wider than 1600 pixels — this preset scales them down. The test series itself does not scale: it shows what compression alone brings at unchanged dimensions. For those 11 images, a median of 31.3 %.
Across all 20 runs the data drops by 27.5 %, from 15.1 MB to 11.0 MB. The lowest measured quality value was 0.98006.
| Sources wider than 1600 px | 11 of 20 |
|---|---|
| Median saving for those sources, without scaling | 31.3 % |
| Saving across all runs | 27.5 % |
| handed back unchanged | 0 of 20 |
| Lowest measured quality value | 0.98006 |
Because the test series does not scale, it is explicitly the floor here: an image scaled down to 1600 px gets smaller on top of this, and the wider the source was, the more so. How much is not measured, and therefore not stated.
Based on the fixed corpus runs of this project: 20 images, quality target SSIM ≥ 0.98, measured under Node with the codec versions from the manifest. Not counted: wide-gamut-p3.jpg — Decision 44: Display P3 profile, decoded without color conversion under Node. Its SSIM under Node is not the one the product delivers; the image tests ICC detection and counts in no statement about quality or size.
The values on this page, with their origin
| Preset | WordPress featured image (wordpress.featured) |
|---|---|
| Target resolution | up to 1600 px wide |
| How the dimensions are read | Budget: smaller images stay unchanged, larger ones are fitted |
| Allowed formats | WebP, JPEG, PNG — chosen by measurement |
| Quality target | SSIM ≥ 0.98 |
| Metadata | removed (EXIF, GPS) |
| Origin of the values | Project value, no outside source |
| Source | none — the value comes from this project’s specification |
| Last checked | – No check date needed |
The width 1600 is set in the project specification 7.2. No platform source is on file; WordPress creates its own responsive variants from the upload anyway. The width is a budget — hence `fit: "max"`.
Platforms change their requirements without notice. That is why every check expires after 90 days and then shows as “Check due” — here and on the presets overview.
The quality target itself is not set but tested: on September 13, 2026 it was held against the eye on the test corpus. It passes narrowly — what exactly that means, and where the method reaches its limits, is on How we measure quality.
Why these values?
1600 pixels wide is a project value, not a figure from the WordPress documentation. It is a budget in the preset, not a rule: if your image is narrower, it stays as it is. If it is wider, it is scaled down to 1600 pixels — keeping its aspect ratio and never scaling up.
The reason to scale before the upload at all lies in the original file. A photo straight from the camera is several thousand pixels wide, and that file stays in the media library. Putting a smaller one into the system affects everything that is later made from it.
Scaling is done only with a dedicated scaler, not through the browser’s canvas. That is not a detail: the canvas result differs from browser to browser, and a quality value that means something different on every device would be worthless. The measurement then runs against the already scaled image — otherwise the scaling damage would be reported as compression damage, and the value would mean something other than what it says.
Frequently asked questions
- Does this replace an optimization plugin?
It works at a different point: before the upload, on the file you put into the media library. A plugin works afterwards, on the server, on what is already there.
TODO(mensch): A documented comparison with the common plugins belongs here — with source and check date. Without it, this page makes no statement about what they do or do not do.
- Do I have to do this separately for every image size?
No. You hand over one file, and WordPress creates its own variants from it.
TODO(mensch): How WordPress creates and embeds these variants belongs here as a documented section — it is this page’s independent specialist text according to the page plan, and it has to come from the documentation, not from memory.
- Is my image enlarged if it is smaller than the target?
No, it is only ever scaled down. Scaling a smaller image up to the target resolution would invent pixels your source does not have: the file would grow and not a single detail would be added.
If the aspect ratio does not match the target, the image is fitted rather than cropped. The result then does not fill the frame, and the tool writes that under the result.
- What does the quality value under the result mean?
It is called SSIM. It compares the result with your source — not byte by byte, but by structure: brightness, contrast and local pattern in small windows across the whole image. 1.000 means the images are identical — that is the value you see when the tool hands your own image back. Below that the distance grows.
The value is measured on every run and shown, including when it comes out badly. How the measurement works, and where it reaches its limits, is on the page about our method.
- Is my image uploaded anywhere?
No. Everything runs in your browser: decoding, measuring and encoding happen on your device, in a background thread. There is no server that receives your image, and therefore none where it could stay behind.
This is not a setting you can flip. It is how the tool is built — there is no counterpart it could send anything to.