A picture message fails in two places. Sometimes it never leaves, and you see an error or nothing at all. Sometimes the carrier delivers it, but the customer sees a grey bubble that says "tap to download" and won't open. Those are different problems with different fixes. Support teams tend to lose an afternoon because they treat them as one.
This checklist puts the causes in order, most likely first. Each step says what to check and what fixes it. We make Ready, so the API examples use our request shapes. The causes themselves are carrier and handset behavior, and they apply on any platform.
Step zero: figure out which failure you have
Before you touch anything, sort the ticket. Your message log tells you which side of the carrier the problem sits on.
| Symptom | Likely cause | First check |
|---|---|---|
| Error on send, nothing delivered | File too large, wrong format, unreachable media URL | File size and type; open the URL in a private browser window |
| Shows "delivered", customer sees nothing | Carrier filtering, or an unregistered sender | Registration status; message content |
| Customer sees "tap to download" that fails | The recipient's device or data settings | Mobile data, MMS toggle, storage |
| Text arrives, picture doesn't | Recipient is a landline or VoIP line, or MMS is stripped en route | Validate the number |
| Works for one person, fails in group threads | Group MMS limits on business numbers | Send one-to-one instead |
If you have an error code, look it up before guessing. Our SMS error codes guide maps the common ones to a cause. If the log says "delivered" and the customer swears it never came, read why business texts don't deliver, because "delivered" only means the carrier accepted the message.
The file is too big or the wrong type
This is the most common cause by a wide margin. Carriers don't publish one shared MMS size limit. In practice, limits vary by carrier and handset, and some networks compress or drop anything large. As a working rule, keep images under 1 MB if you want them to arrive on most US carriers. A 4 MB photo straight off a phone camera often fails or gets crushed into mush.
What to do:
- Resize before you send. A product photo or flyer at 1000 to 1200 px on the long edge, saved as a JPEG at moderate quality, usually lands in the low hundreds of KB and still looks sharp on a phone.
- Stick to boring formats. JPEG, PNG and GIF are the safest choices. HEIC (the default iPhone camera format), WebP, TIFF, large animated GIFs and video files are where support breaks down by carrier.
- Watch PDFs. A PDF often shows up as an attachment the customer can't open, or doesn't show up at all. A screenshot of page one plus a link to the full document is usually more reliable.
The media URL can't be fetched
When you send a picture through an API, you usually don't upload the file. You pass a URL, and the platform fetches the image from it. If the fetch fails, the message fails. On Ready the request looks like this:
POST https://api.tryready.com/v1/messages
X-API-Key: <key>
Idempotency-Key: 6f1c2a9e-3b7d-4e0a-9c51-2d8f4b7a1e03
{
"to": "+12125550199",
"body": "Here's your quote. Reply with any questions.",
"media_url": "https://cdn.example.com/quotes/1042.jpg",
"consent_attested": true
}Things that break the fetch:
- The URL needs a login or a session cookie. It has to be publicly reachable. Paste it into a private browser window. If you get a sign-in page, so does the fetcher.
- Signed URLs that expire. A short-lived signed S3 link can expire before a queued message goes out. That includes a message held for the recipient's quiet hours. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
- The URL points at a web page, not an image. A share link from a cloud drive often returns an HTML preview page instead of the file itself.
- Wrong content type. If your server labels a JPEG as
application/octet-stream, some pipelines reject it.
Send the Idempotency-Key on every request. If your retry logic fires after a timeout, the customer still gets one picture, not three. The full field list is in the messages API docs, and our MMS API post covers building picture sends into an app.
The customer's phone isn't set up for MMS
If the picture shows up as "tap to download" and fails, the carrier did its part. The problem is on the handset. SMS travels over the voice signaling channel. MMS needs mobile data. That one fact explains most of these tickets.
A script your support team can read to the customer:
- Turn on mobile data. Many phones won't download MMS over Wi-Fi alone, even when Wi-Fi is working fine.
- On iPhone, check Settings > Messages > MMS Messaging is on. If it's off, pictures from non-iMessage senders won't come through.
- Free up storage. A full phone fails downloads without saying why.
- Restart the phone. This is boring advice, and it fixes a surprising share of stuck downloads.
- Check whether the customer is roaming or on a prepaid plan with data off. Either can block MMS downloads entirely.
There's nothing to fix on your side here, so don't resend. Every resend is another paid message, and it will fail the same way.
The number on the other end can't take pictures
Landlines can't receive MMS. Many VoIP and app-based numbers handle MMS badly or not at all. If a contact entered their office line on a form, your text may never arrive, or the picture gets stripped.
You can check before you send. GET /v1/validate/:phone tells you whether a number is mobile, landline or disconnected. See our phone number validation API post. Ready already refuses numbers its own sends have seen as landlines, on every account and at no charge. You can also switch on landline validation for the account to look up the rest and refuse those too. It costs $0.003 extra per segment when switched on and is off by default. Opt-outs and numbers on your Ban list are refused up front either way, and you aren't charged for them.
Group threads
A customer adds your business number to a group text with their spouse and a contractor. Your reply doesn't show up for everyone, or the picture gets lost. Group MMS on business numbers is unreliable across US carriers. Registered business traffic is built for one-to-one conversations, and group threads fall outside that design.
The practical fix is to message each person one-to-one. If group conversations are central to how you work, a blue line is worth a look. Ready's blue line sends as iMessage, and replies, reactions and group chats land in the same inbox thread as your SMS. Two limits apply: a blue line only sends photos after the person has replied, and it only reaches iPhones. Texts to Android phones go from the account's regular number. The blue line costs $99 a month per line plus 6 cents a segment. Details are in the blue line guide.
Carrier filtering, and when registration actually fixes it
Suppose the file is small, the URL works, the number is a mobile line, and pictures still vanish after showing "delivered". In that case, look at your sender. Carriers filter unregistered business traffic hard, and pictures from an unregistered number are an easy target.
Registration fixes this when the cause is that you're unregistered. On Ready, an account can send up to 500 texts a month before it registers. After that, you have to register. Registration happens in-app with no setup fee. The first month is $25 at submit. After that it's $25/mo for registration and $2 per number. Most approvals take 2 to 7 days. Check where you stand with GET /v1/registration.
Registration doesn't fix content. Carriers still look at what you send. That includes public link shorteners, wording that reads like spam, and images that look like promotional flyers on a campaign you registered for reminders. If you're registered and still filtered, the cause is usually content-level filtering, which registration doesn't touch.
When to skip MMS entirely
Sometimes the most reliable picture message has no picture in it. A short text with a link to the image on your own domain avoids file limits, device settings and landline problems in one move.
Worked example (assumptions stated): You need to send 2,000 opted-in customers a reminder with a product image. The text version is 140 GSM characters with a link on your own domain and no emoji, so it's 1 segment. At the Standard rate that's 2,000 × $0.0075 = $15, plus 2,000 × $0.0045 in carrier fee. That total excludes the compliance surcharge if scrubbing or landline validation is switched on. Add an emoji and the same 140 characters become 3 segments, so you'd triple the bill.
MMS is priced differently from SMS segments. On Ready an MMS is a flat $0.021 plus a $0.0095 MMS carrier fee, $0.0305 all-in, so compare that with the segment math before you assume one is cheaper. How to avoid paying for MMS walks through when the link approach wins. The tradeoff is real: a link is one extra tap, and a picture in the thread gets seen even by people who don't tap.
The short version
Sort the ticket first. An error on send almost always means the file or the URL. "Tap to download" means the customer's phone. "Delivered" with nothing visible points to your sender or your content. To prevent most of it, keep images under 1 MB as JPEG or PNG, use public URLs that don't expire, validate numbers you aren't sure about, and stop sending pictures into group threads. Get registered before you reach the unregistered monthly limit.
If you want to test your own setup, the first 20 texts on Ready are free (one-to-one sends, card on file required), so use them before you register. Sign up here, send a picture to your own phone, and work through this list on a message you control.