Goal

Figure out why an image that looks fine in your WordPress site shows up blank, broken, or as a placeholder in the native app — and fix it.

Your app doesn’t store images itself. It receives a list of image URLs in its payload — the bundle of data the app downloads from your site — and fetches each file over the network only when it’s time to show it. So “won’t load in the app” almost always comes down to one of two things: the URL MAM sent was wrong or empty, or the app couldn’t fetch that file from a phone. Below are the likely causes, in order from most common to least.

Prerequisites

• The image is uploaded and visible somewhere in WordPress (Media Library, a product, a post, or an App Setup panel).
• Access to Mobile App Manager → App Setup for app-level images (icon, splash, logo, background), or to the relevant content (product, post, category) for content images.
• For the network checks, a way to open a URL in a phone browser — ideally on cellular data, not just office Wi-Fi.

If no images are loading — every image in the app is broken — that points at a site-wide network or HTTPS problem. Jump to Step 3 and Step 4 first.

How images reach the app (the short version)

When the app asks for its data, MAM builds a payload that includes image entries. For app-level assets (app icon, splash screens, background, logo), MAM looks up each image and records two things: its url and its extension (the file type, derived from the URL — for example png, jpg, jpeg, webp). The app uses the URL to download the file and the extension to decode it.

That process has two consequences, and between them they explain most “won’t load” reports:

• If the stored image is gone, so is the URL. MAM finds app images by looking up their Media Library attachment. Delete that attachment, and the lookup comes back empty — there’s no image entry left to send.
• The extension is read literally off the URL. MAM just takes whatever text follows the last . and calls that the file type. A URL with no real file extension — or one with a query string or CDN transform tacked on the end — can hand the app an extension it doesn’t recognize, so a perfectly good file gets rejected.

Keep both of these in mind as you work through the steps.

Steps

1. Confirm the format is one the app supports

Stick to standard web image formats — JPG/JPEG and PNG are the safest bets, with WebP also holding up well on current devices. Steer clear of:

• HEIC/HEIF (the format your iPhone camera uses by default). These slip into the Media Library straight off a phone all the time, and they look fine in WordPress because your browser can decode them — but the app’s image loader often can’t.
• SVG and other vector or exotic formats for content images.
• A file whose real type doesn’t match its extension — say, a JPG that got renamed to .png. MAM trusts whatever extension shows up in the URL, so a mislabeled file ends up handed to the wrong decoder.

If it’s just one image causing trouble while the rest work fine, re-save it as a clean JPG or PNG, then re-upload and re-select it.

2. Make sure the media file actually still exists

This is the most common reason one specific image disappears in the app while everything else keeps working fine.

• Open the Media Library and confirm the image is still there and opens.
• For app-level images (icon, splash, background, logo), reopen the relevant App Setup panel and confirm the image still shows in its picker. If the panel looks empty or shows a broken thumbnail, the underlying attachment was likely deleted — re-upload and re-select it, then save.
• For product or post images, open that item and confirm its featured image / gallery image is still attached.

If the file was deleted from the Media Library — or its attachment record was removed — but the content still references it, MAM has no URL left to send, so the app shows nothing or a placeholder. Re-attach a valid image and you’re set.

3. Check that the URL is HTTPS, not HTTP

Phones don’t take chances with transport security. Both iOS and Android block — or just silently fail — plain http:// image loads by default. So if your site is serving some media over http:// (common right after an SSL migration, or when a CDN/origin URL got hardcoded somewhere), those images will look fine in a desktop browser and still fail on device.

To check:

• In the app, find a broken image and, if you can, get its URL (or reproduce the same image in WordPress and copy its file URL).
• Confirm the URL begins with https://.
• If any image URLs are coming through as http://, fix it at the source: make sure your WordPress Address and Site Address (Settings → General) are https://, run a search-replace to update old http:// media URLs in the database, and confirm your CDN/origin is serving over HTTPS.

Once the URLs are corrected, re-save the affected App Setup panel (or re-fetch the app data) so MAM rebuilds the payload with the fix baked in.

4. Open the image URL on a phone, on cellular data

Of everything here, this test tells you the most about what’s really going on.

• Copy the image’s file URL.
• Paste it into the browser on a phone, with Wi-Fi off so you’re on cellular.
• Watch what happens:
  Image displays → the file is reachable; the problem is more likely format (Step 1) or the extension being misread (Step 6).
• 404 / “not found” → the file is missing or the path is wrong (back to Step 2).
• 403 / “forbidden”, or it loads on your office Wi-Fi but not on cellular → this is a hotlink-protection or firewall issue (Step 5).
• A tiny or generic placeholder image → your store may be serving a “no image” placeholder because the real image isn’t attached (Step 2).

5. Rule out CDN, hotlink protection, and firewall blocking

If the URL loads fine from your office but not from a phone, something out there is blocking requests that don’t come from your website:

• Hotlink protection. Many CDNs, security plugins, and hosts can block image requests whose Referer isn’t your own domain. The app’s requests come in with no referer (or one that isn’t your website), so hotlink protection reads that as theft and blocks it. Allow-list the app, or disable referer-based hotlink protection for your image directories.
• CDN signed/expiring URLs. If your CDN generates URLs with an expiring token, that token can go stale before the app even fetches the image — or it can change the tail of the URL enough to break the extension (see Step 6). Stick with plain, stable image URLs for app content.
• WAF / firewall rules (Cloudflare, Wordfence, a host-level WAF) that challenge or block “non-browser” clients. An image loader can’t solve a CAPTCHA or JS challenge, so the image just fails. Allow-list your image paths, or relax the rule for media requests.

6. Watch for URLs with no clean file extension

Because MAM reads the file type off the end of the URL, anything that changes that tail can break the extension even when the file itself is perfectly fine. Here’s what tends to cause trouble:

• A CDN transform like .../image.jpg?width=800&format=auto (the literal “extension” becomes the query string).
• A URL that ends in the file name with no extension at all.
• A dynamically generated image endpoint (.../get-image/12345).

If an image opens fine in a phone browser (Step 4) but still won’t render in the app, a malformed extension is the likely culprit. Point the content at a direct Media Library URL ending in a normal image extension (.jpg, .png, .webp) instead of a transformed, tokenized, or extensionless one.

7. Re-fetch the app data and re-test

Even after a fix, the app might still be showing cached data. Here’s how to force a fresh payload:

• Re-save the App Setup panel or content you changed (saving invalidates the cache).
• In the app, fully close and reopen it, or trigger a refresh, so it pulls the updated data and re-downloads the images.

Troubleshooting quick reference

What’s next

• If the broken image is your app icon, see Upload your app icon (and avoid the Apple alpha-channel rejection) — icons have their own format and flattening rules.
• If splash / launch screens are the problem, see the launch-screen setup article.
• If product images specifically are missing, check that each product has a featured image attached in WooCommerce.

Related

• Upload your app icon (and avoid the Apple alpha-channel rejection)
• Set your app’s launch screen (splash)
• Why my changes aren’t showing up in the app (caching)