Why Images Break After Offloading WordPress Media (and How to Prevent It)
Images usually break after an offload for one of a few reasons: a file never reached the bucket, a thumbnail was made after the upload ran, the bucket isn't public, or the page points at an address that doesn't serve the file. You can tell which by opening the broken image's address directly in your browser.
How do you diagnose a broken image?
Right-click the broken image's space, or use your browser's developer tools, and copy its address. Open it in a new tab, then find what you see here:
| What you see | Likely cause | What to do |
|---|---|---|
| Not found (404) | The file isn't in the bucket at that path | Upload it again, then check it's there |
| Access denied (403) | The file may be there, but it isn't public | Allow public reads on the bucket, or fix the domain's access rules |
| Can't connect, or a certificate error | The domain or its certificate isn't set up | Finish connecting the domain, and wait for its certificate |
| The address looks wrong | The bucket, region or path in your settings is wrong | Compare it with the file's real address in your provider's dashboard |
| It opens fine, but not on the page | A cached page, or http on an https page | Purge your page cache, and use https for the media address |
| The old image still shows | A CDN or browser is holding an old copy | Purge the CDN, then test in a private window |
| Only the local address appears | The cloud copy isn't being used yet | Check the file's status in your offload plugin |
Why do only some sizes break?
WordPress turns one upload into several files, and a page asks for whichever size fits. So the full image can work while a thumbnail fails, and only some phones or layouts show the problem.
A thumbnail came late. WordPress creates sizes after the upload starts, and other plugins can add more. An offload that runs too early misses them.
WordPress never made that size. The size may have been added after the image was uploaded, or another plugin deleted it.
Your theme makes its own sizes. Some themes and plugins resize images on request, outside WordPress's list of registered sizes. An offload tool may not know those files exist, so check how yours handles them.
Why doesn't regenerating thumbnails fix it?
Regenerating needs the original file on your server. If local copies were removed, the tool has nothing to work from. Bring the originals back first, regenerate, then let the new sizes upload.
A new size also needs a new upload. Regenerating only changes your server, so check that the cloud copy arrived too, then purge your CDN.
Why are other files missing from the bucket?
The upload stopped partway. A timeout or an outage interrupted it, and an upload can look finished when part of it failed. Check the file in the bucket, rather than trusting the upload step.
A changed file wasn't sent again. An image editor or optimizer changed the local file after it was uploaded, so the two copies no longer match.
Why would a file in the bucket not load?
- The bucket or file isn't public.
- The custom domain isn't connected, or leads to a different bucket.
- The address uses http on an https page, and browsers block that.
- A CDN is holding an old copy, or an old error.
How do you prevent it?
- Check each file in the bucket before your site uses it, including every size.
- Wait for WordPress to finish creating sizes before uploading.
- Keep local copies until you're confident, so there's a fallback.
- Test public delivery with a real image before switching.
- Avoid rewriting your database, so you can go back.
How does Offloft handle this?
Offloft waits for WordPress to finish, checks each file in the bucket, and keeps serving the local copy until the check passes. A missing size becomes an issue with a fix, which creates the size, uploads it and checks it. You can recheck your library any time with the free plugin, or on a schedule with Pro. The delivery check tests the public address before anything switches.