Compress Before Upload: When It Works and When It Falls Apart

“Compress your images before you upload them” is one of the oldest pieces of WordPress advice around. It’s also one of the least examined.

The short answer: once ShortPixel is running on your site, you don’t need to compress or optimize your images yourself before uploading them. That’s ShortPixel’s own documented position, and it comes with a warning attached, doing the work first risks over-optimizing the file. Upload a good original and let the plugin handle the compression.

The longer answer is that “compress before upload” bundles four different jobs together. Plugins took over most of them years ago, and WordPress 7.1 moved a good part of the rest into the browser. What’s left is worth knowing, because it isn’t the part most people mean.

What “compress before upload” actually means

The phrase bundles four separate jobs together, and they don’t behave the same way once the rest of the pipeline is in the picture.

Step	What it does	Handled after upload?
Resizing	Reduces pixel dimensions	WordPress scales very large uploads on its own, and ShortPixel can apply a resize limit of your choosing
Format choice	Determines JPEG, PNG, WebP, AVIF	Partly. You pick the source format; ShortPixel can generate the WebP and AVIF counterparts
Metadata removal	Removes EXIF, GPS, IPTC	Yes, and you decide whether to strip it or keep it
Lossy compression	Re-encodes the image to reduce file size	Yes. This is the optimizer’s whole job

When someone says “I compress before upload,” they almost always mean the last row. That’s also the row that causes trouble.

What happens after you hit upload in WordPress 7.1

WordPress 7.1, released in August 2026, changed where image processing happens. There are now two paths, and which one you get depends on browser support plus a few runtime conditions.

On the client-side path, the browser handles compression, resizing, format conversion, EXIF rotation, and thumbnail generation locally using a WebAssembly build of libvips. It’s on by default, but only in Chromium browsers from version 137, and only when the device and connection clear a few thresholds. Firefox and Safari fall back to the old server-side path using GD or Imagick, as do low-memory devices and slow connections. The isolation headers that make the feature work are sent on editor screens, so dragging a file straight into the Media Library still takes the server path too.

Either way, three things stay the same. Your PHP settings still have to accept the file, so upload_max_filesize and post_max_size can stop a large upload before anything else happens. The 2560px big-image threshold still applies. And wp_generate_attachment_metadata still fires, which is why optimization plugins keep working normally on both paths.

Two details matter for this discussion. First, the browser uploads the original plus every generated size, so total upload bytes go up on the client path rather than down. Second, and more importantly, WordPress builds the smaller copies from the file you gave it rather than degrading that file. Sites using the image_editor_output_format filter are converting the upload deliberately, which is a separate decision.

Which means the source you upload is still the source everything downstream works from. For a typical JPEG or PNG, ShortPixel then optimizes the selected files and thumbnails and can generate WebP or AVIF counterparts. If your source was already aggressively compressed, that lost detail isn’t coming back at any stage.

What the automatic pass covers that you can’t

Part of why the manual step stopped paying off is that the automatic one reaches further.

Every generated size gets optimized, not just the file you exported. A library with fifteen registered sizes means fifteen files per upload, and nobody compresses those by hand. WebP and AVIF counterparts are created alongside the originals and served to the browsers that support them. The same settings apply to every upload from every editor on the site, including the ones who won’t follow your workflow. It runs retroactively across images already in the library, which is the one thing pre-upload work can never fix. And with backups on, all of it is reversible.

None of that is available to you in an export dialog.

When work before upload still makes sense

The list of situations where handling something yourself first still pays off is shorter than it used to be. It isn’t empty.

Your server rejects the file. ShortPixel itself accepts any image size, but the file has to reach WordPress first. If you’re seeing “exceeds the maximum upload size for this site,” resizing locally is the fastest fix available to you. Raising the limit means editing PHP settings or asking your host, and on managed hosting you often can’t.

Thumbnail generation is failing. This used to be the strongest argument for shrinking files first, and WordPress 7.1 took a lot of the sting out of it, since sub-sizes built in the browser don’t touch PHP’s memory limit at all. The catch is how often the fallback path still runs: Firefox, Safari, older WordPress versions, modest devices, and Media Library uploads all still go through GD or Imagick, where a 45-megapixel file can produce a “post-processing failed” error. If that’s your editors’ setup, resizing first is still a practical workaround.

You’re uploading in bulk over a slow connection. Three hundred photos at 9 MB each is a lot of data moving before anything gets optimized, and on the client-side path it’s more than it used to be, because the original and every generated size go up separately. Resizing the source shrinks everything derived from it.

Your backups are getting expensive. WordPress keeps the true original. With Backup originals enabled, which is the default, ShortPixel keeps its own copies of what it optimizes so you can restore them. Multiply that by nightly site backups and it adds up. Uploading 2560px files instead of 6000px ones, while keeping the full-resolution masters somewhere off the site, changes the storage math permanently.

You’re using Adaptive Images with very large originals. ShortPixel’s documentation strongly advises getting those originals resized, since SPAI works from the file sitting on your server. Worth noting that it recommends automating this with a plugin rather than doing it by hand, which is the right instinct in general.

The images never touch the Media Library. Theme assets, files committed to a repo, images going into an email, a PDF, or a client handoff. No upload hook fires, so nothing runs.

Notice the pattern. Almost every reason on that list is about dimensions, transfer, or disk space, not about squeezing quality out of a file. The one real exception is images that never enter the pipeline at all, and those you do have to handle yourself, because nothing else will.

When it falls apart

You compress twice, and the second pass has nothing to work with. JPEG compression is lossy, so every new encode starts from information that has already been thrown away. Recompressing an already-squeezed JPEG can compound artifacts and reduce quality while the savings get smaller and smaller. If you know your source has been through a lossy pass before, Glossy or Lossless is the safer setting.

Your savings report looks smaller than expected, so you blame the plugin. Two separate things can cause this. Pre-compressed uploads often leave nothing to take, and ShortPixel only spends a credit when it can improve an image by at least 5%, so you’ll see low numbers and no charge. Separately, the libvips encoder in WordPress 7.1 produces JPEGs roughly 15% smaller than GD or Imagick did, so sub-sizes now arrive already better encoded than they used to. Neither case is a defect. In both, the headroom was gone before the optimizer saw the file.

The WebP version gets dropped. If the WebP or AVIF file comes out more than 5% larger than the compressed JPEG or PNG, ShortPixel discards it rather than shipping a heavier file. Compress a JPEG hard enough beforehand and there may simply be no size advantage left for a next-gen version to capture. That isn’t a conversion failure. You narrowed the gap yourself, and you did it by lowering the quality of the source.

You can’t take it back. The backup folder holds whatever you uploaded, which means restoring an over-compressed file gives you the damage back, faithfully. Every future re-optimization starts from that compromised copy. Worth thinking about, because AVIF wasn’t in most pipelines three years ago and something will eventually replace it. That upgrade path only exists if a clean master still exists somewhere. It’s the same reason it matters what happens to your files when you uninstall an optimization plugin.

Metadata disappears before you’ve decided. Plenty of free online compressors strip EXIF and IPTC by default, copyright fields included. If that matters to you, handle it in the plugin, where it’s a setting you can switch back off. There’s more on how compression and copyright information interact if you want the detail.

You set a quality ceiling that machines now notice. Blurry, over-compressed images are harder for AI crawlers to interpret than clean ones, because object recognition and OCR both work better on sharp source material. Compressing aggressively before upload puts a floor under image quality that no plugin can lift later.

A workflow that works either way

1. Keep the full-resolution master off the site. Drive, Dropbox, a NAS, anywhere that isn’t wp-content/uploads. This is the only step you can’t retrofit later.
2. Export to a maximum dimension that matches the largest size your site actually needs. Don’t go below your largest registered image size, because that limits what WordPress can regenerate later if your theme changes.
3. Export at high quality, not small size. If your workflow needs a JPEG export, keep the quality high rather than hunting the smallest possible file yourself. You’re supplying good source material, not producing the final web asset.
4. Pick the source format by content, not habit. JPEG for photographic material. PNG when you need a lossless raster or transparency, including screenshots and UI captures, where lossy compression smears text and hard edges. SVG for vector assets like logos and icons, once you’ve set up SVG uploads safely. If JPEG or PNG is your source, let ShortPixel generate the WebP and AVIF counterparts rather than making them first.
5. Set the safety net once. Under Settings > ShortPixel > Image Optimization, turn on Resize large images and pick your maximum dimensions. It applies to the full original only, not the thumbnails, and it catches every upload from every editor on the site. Keep Backup originals on while you’re at it, which is the default.
6. Trim the thumbnail sizes you don’t use. A theme that registers twenty sizes can mean twenty extra files per upload, and every thumbnail that gets successfully optimized can use its own credit, with WebP or AVIF generation adding more. On sites with a lot of registered sizes, excluding the ones you don’t actually serve makes a real difference.
7. Don’t run a second compressor first. One tool owns the lossy pass. That’s the whole rule.

It’s also worth checking what your host does before you configure anything, since some managed platforms already handle part of the image pipeline for you.

Conclusion

With ShortPixel installed, you don’t need to compress or optimize your images before uploading them. ShortPixel handles everything for you without you needing to do anything before or after uploading the images.

What’s left over is narrower than the old advice suggests. Resize when dimensions, upload limits, transfer time, or storage give you a concrete reason to. Keep your masters safe. Then let one tool own the compression, because two tools doing the same job to the same file don’t stack their savings. They stack their damage.

FAQs