Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

Why Your Uploaded Image Isn’t the File Your Page Is Using

Field Note #126
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You upload a background image at a specific filename, reference that exact filename in your CSS, and it works. Later, you upload a replacement image at that same size — and something about it looks subtly different than what you tested locally, even though it’s the same file.
Nothing about your CSS changed. The image itself didn’t get corrupted. WordPress just quietly gave you a different file than the one you uploaded.

What’s actually happening
WordPress automatically downsizes any image wider than 2560px on its longest edge. It keeps your original in the Media Library for reference, but the file it actually serves — and the one saved at what looks like your original filename — is a scaled version, often with -scaled appended before the file extension.
If your CSS or HTML references the un-scaled filename directly, this can create a mismatch: WordPress’s own front-end output may point to the -scaled version while you’re editing/testing against what you assume is the original. In a caching-heavy setup (Autoptimize, WP Super Cache, CDN), this can compound further, since each layer might be caching a different generation of the file.

How to tell the difference
Check the image’s actual dimensions in the Media Library before uploading anywhere large-format (hero backgrounds, wide section backgrounds). If it’s over 2560px wide, assume WordPress will silently create a second version of it the moment it’s uploaded.

The fix
Resize and compress the image to under 2560px on the long edge before uploading it, so WordPress has no scaling decision to make in the first place. This also has the side benefit of a smaller file size and faster load — there’s rarely a reason a background/hero image needs to exceed that width for web display anyway.

How to avoid it next time
Make “check dimensions against 2560px” a standard step before uploading any large background or hero image — right alongside compressing it. It’s a single check that prevents a whole category of “why does this look different than what I uploaded” confusion later.

Tagged in :

More from the field