Error 131053: Media Upload Error

Error 131053 is WhatsApp saying it cannot process an attachment. It is confusing because the file uploaded without complaint, so the problem only appears once the message has been sent, and the message that had looked fine in the thread turns into a failure. In almost every case the file itself is fine: it is simply in a format WhatsApp does not accept for that kind of message.

Symptom

You attach a photo, the message appears in the conversation, and a short time later it is marked failed with a reason close to "Media upload error (131053). The attachment could not be processed by WhatsApp." Text messages to the same customer keep working, other photos may go through normally, and nothing about the number, the template or the 24-hour window is involved.

If it happens on several images in a row, they usually have one thing in common: they came from the same place, such as a batch saved from a website, exported from the same design tool, or shared into a folder by a colleague.

Why it happens

WhatsApp's rules for media are narrower than a file picker suggests, and they are Meta's rules rather than anything a platform can widen:

The single biggest cause of 131053 is webp. It is the format most images on the web are saved in now, most browsers give it to you when you right-click and save a picture, and plenty of design and screenshot tools export it by default. WhatsApp accepts webp only as a sticker. As a photo it is refused. GIF is not accepted at all, in any form.

What makes it awkward is the timing. Meta's own media endpoint stores a webp happily, because it is a legitimate sticker file, and only the send refuses it. So the upload looks successful, the message is created, and the failure arrives afterwards. That gap is exactly why the error feels like something broke rather than something being the wrong shape.

An image can also trip 131053 by being too large. WhatsApp caps images at 5 MB, well under the limit for video or documents, and a modern phone photo can exceed it easily.

What VGraple CRM does about it automatically

You should rarely meet this error in VGraple CRM now, because the conversion happens when you attach the file rather than being left to you:

• A webp or GIF becomes a JPG. If the image carries transparency, it becomes a PNG instead, so a logo on a clear background does not come out with a white box behind it.
• An oversized image is brought under WhatsApp's 5 MB cap. It is resized to fit rather than refused, so a large photo from a phone still sends.
• An iPhone HEIC photo becomes a JPG, which has been true for longer and is the same idea.
• The rotation is preserved. Phones record orientation separately from the pixels and WhatsApp does not read that back out, so the correction is applied during conversion instead of arriving sideways.
• Animated images are refused at the point of attaching, with the reason, because converting an animation to one still frame would send something you did not choose. Export it as an MP4 and send that instead.
• Formats WhatsApp will never take are refused immediately, with the supported list in the message, rather than being accepted and failing later. WAV audio is the common example.

The principle is worth stating plainly, because it is what makes the error rare: nothing should be accepted at attach time that WhatsApp will reject at send time. A refusal you see while composing costs you five seconds. A refusal that arrives after sending costs you a message you believed had gone.

Fix

1. For a new message, just attach the file again. Conversion happens on the way in, so a webp, GIF or oversized photo is handled for you.
2. For a message that already failed, do not rely on Retry. Retry re-sends the same stored file, which is the one WhatsApp already refused, so it fails the same way. Attach the image again in a fresh message instead.
3. If you are sending through the API or another tool, convert before uploading: JPG or PNG for photos, MP4 for anything animated. The list above is the whole of what WhatsApp accepts.
4. If an image is enormous, check it is genuinely a photo and not a print-resolution export. A 40 MB TIFF-sized PNG is not what a customer needs on a phone, and reducing it improves delivery as well as their data usage.
5. If the file is genuinely corrupt, which is rare but does happen after a bad transfer, open it once to confirm it still renders, then re-save it before attaching.

How to tell 131053 from other failures

131053 is about the file. It is not about the recipient, the window or your number, so it is worth separating from the errors that look similar in a busy inbox:

• Error 131026 means the message could not be delivered to that person: not on WhatsApp, blocked, or an app too old to receive it. The attachment was fine.
• Media not loading is the inbound direction: something a customer sent you that has expired at Meta or failed to fetch. Different problem, different fix.
• Messages delayed or held covers messages that sit in Sent without ever failing, which is pacing rather than a rejection.

A failed message always keeps its reason on the row in the conversation, so if you are unsure which of these you are looking at, the error text on the message itself is the fastest answer.

Prevention

If your team sends product photos, agree on one export format and stick to it. JPG for photographs, PNG for anything with transparency or crisp text, and MP4 for anything that moves. Where images come from a website or a shared drive, be aware that webp is now the default in most of those pipelines, which is exactly why this error became common enough to be worth its own page.

For anyone building on the API, validate the format at your own upload step rather than at send time. That is the same lesson in a different place: the earlier a wrong file is caught, the cheaper it is, and the further away from a customer conversation the failure happens.