Preparing images for WordPress without bloating your media library

WordPress does more with an uploaded image than most people realise, and the defaults are generous in a way that quietly costs you storage, backup time and page weight. Understanding what happens on upload changes what you should upload.

What happens when you drop in a file

A single upload produces several files. WordPress core generates thumbnail, medium, medium-large and large sizes by default. Your theme almost certainly registers more — a card size, a hero size, a slider size. A commercial theme with several layouts can register a dozen.

Upload one 8 MB photograph and you may have created fifteen files totalling 20 MB. Multiply by a few hundred posts and the media library becomes the largest thing in your backups, which is why site migrations take so long.

The original is also kept, untouched, forever. That is the right default — WordPress cannot know what sizes you will need later — but it means the file you upload sets the floor for everything.

Upload dimensions that make sense

The useful question is not "what is the maximum" but "what is the largest size this image will ever be displayed at, on the highest-density screen I care about".

For most content-width images in a standard blog layout, that is around 1600 pixels wide: an 800-pixel content column at 2× density. Full-width hero images need more, typically 2000–2560 pixels. Anything beyond 2560 is rarely justified outside photography portfolios where the image is the content.

WordPress caps its own big_image_size_threshold at 2560 pixels by default and will generate a scaled version above that, keeping your original as -scaled. If you are uploading 6000-pixel camera files, you are storing two copies of an image nobody will ever see at full size.

Pre-resizing a batch before upload means you skip that entirely.

File size and the upload limit

Hosts commonly cap uploads at 2, 8 or 64 MB depending on the plan, and the error when you exceed it is not always clear. A 1600-pixel JPEG at quality 85 lands comfortably under 500 KB for most photographs, which removes the problem rather than working around it.

Compressing before upload also means WordPress's generated sizes are derived from an already-sensible source. Its own resizing quality defaults to 82 for JPEG, which is reasonable, but it cannot recover from a source that was oversized to begin with.

srcset does the rest

Modern WordPress emits a srcset attribute listing the generated sizes, so a phone downloads a smaller file than a desktop without any effort on your part. This works well, and it is a reason not to fret excessively about the exact upload dimension — as long as your source is large enough for the biggest registered size, the responsive machinery handles the rest.

What it cannot do is invent detail. If your largest registered size is 1600 and you upload a 900-pixel image, WordPress will not upscale it; it will simply serve the 900-pixel file to everyone, and it will look soft on a laptop.

Filenames become URLs

The uploaded filename becomes the media URL and the default title in the media library. DSC_4821.jpg produces a URL that says nothing and a library entry that is unfindable six months later.

Renaming a batch before upload — harbour-sunset-boats.jpg, harbour-sunset-pier.jpg — costs one setting in a batch tool and produces URLs that describe their content. WordPress will not let you change a filename after upload without a plugin and a redirect, so this is genuinely a do-it-first task.

Cleaning up an existing library

If you have inherited a bloated library, the order of operations matters:

1. Audit what sizes your theme actually uses. Registered sizes that no template calls are pure waste.
2. Deregister the unused ones in your child theme, so future uploads stop generating them.
3. Regenerate thumbnails with a plugin so existing images match the new set — this deletes the orphaned files.
4. Only then consider bulk-compressing what remains.

Doing this in the reverse order means compressing files you are about to delete.

A pre-upload batch, concretely

For a typical content site, one pass before upload handles everything:

• Resize with a maximum width of 1600 pixels, with upscaling disabled so smaller images pass through untouched.
• Convert to WebP at quality 82, or stay on JPEG if a plugin in your stack is fussy about it.
• Rename descriptively, hyphens and lowercase.

That produces files that are correctly sized, appropriately compressed, and named in a way that survives into the URL. WordPress then generates its variants from a good source instead of an oversized one, and your backups stop growing at the rate they were.

The plugin question

Compression plugins that optimise on upload are convenient, and many of them work by sending your images to a third-party service for processing. That is a reasonable trade for some sites and unacceptable for others — client work under NDA, medical or legal imagery, anything with people who did not consent to their photographs being handed to an optimisation vendor.

Processing locally before upload sidesteps the question, costs nothing per image, and leaves your originals on your own machine.