Error 131053 is where a lot of otherwise-working integrations break the first time they send something other than text. Meta documents it as "Media upload error," with details stating it is unable to upload the media used in the message, an HTTP status of 400, and a recommended action of inspecting media files to confirm they match supported types and verifying the MIME type (Meta for Developers, WhatsApp error codes reference, retrieved 2026-08-20).
The phrase "verify MIME type" is doing more work than it appears to. The most common cause of 131053 is not an unsupported file format — it is a supported file whose declared MIME type does not match its actual contents, or a hosted URL that serves the wrong Content-Type header.
This guide covers the difference between the two ways to attach media, what actually gets rejected, and why hosted links fail more often than direct uploads. For the wider failure surface, our WhatsApp Business API error codes reference indexes the rest.
Two Ways to Attach Media, Two Failure Surfaces
The Cloud API accepts media in two forms, and they fail differently.
Uploaded media (id). You upload the file to Meta first and receive a media ID, then reference that ID in the send. Failures happen at upload time, which is good — you find out before the campaign runs.
Hosted media (link). You supply a publicly reachable URL and Meta fetches it at send time. Failures happen during send, and they include everything that can go wrong with an HTTP fetch on top of everything that can go wrong with the file itself.
Uploaded ( | Hosted ( | |
|---|---|---|
When it fails | At upload | At send |
Failure surface | File validity only | File validity + fetch |
Needs public hosting | No | Yes |
Handle lifetime | Short-lived | As long as the URL serves |
Best for | Campaigns, repeated sends | One-off dynamic assets |
Prefer uploaded media for anything you send more than once. Validating at upload time turns a send-time incident into a build-time check, and one upload reused across a campaign is far fewer moving parts than thousands of fetches against your CDN.
What Gets Rejected
Cause | Signature | Fix |
|---|---|---|
Declared MIME type does not match contents | Supported format still rejected | Detect type from file bytes, not extension |
Genuinely unsupported format | Every send of that asset fails | Convert to a documented supported type |
File exceeds the size limit for its type | Larger files fail, smaller ones succeed | Compress or resize before upload |
Hosted URL not publicly reachable | Works in your browser, fails from Meta | Remove auth, allowlists, and signed-URL expiry |
Wrong | Correct file, rejected fetch | Configure the server to serve the real type |
Redirect chain on the hosted URL | Intermittent failures | Serve the asset directly, no redirects |
Expired or foreign media ID | Worked yesterday, fails today | Re-upload; do not cache IDs long-term |
Corrupt or truncated file | Consistent failure on one asset | Re-encode from source |
The MIME type mismatch
This is the cause Meta's recommended action points at, and it is the one that feels unfair because the file is a supported format.
The situation: a file named receipt.pdf that is actually a JPEG, or logo.png that a design tool exported as WebP. WhatsApp validates the declared type against the actual bytes and rejects the mismatch.
It happens because file extensions are metadata that anyone can set, and content pipelines rename files constantly — a CMS export, a user upload, a batch conversion that changed contents without changing names.
Detect the type from the file's contents server-side. Every language has a way to sniff magic bytes (python-magic, file, equivalents elsewhere). Trust that, not the extension, and set the declared MIME type from what you detected. This single change eliminates the largest cause of 131053.
Why hosted links fail more
A link adds an HTTP fetch performed by Meta's infrastructure, from outside your network, with no session and no credentials. Four things break there and none of them are visible when you test the URL in your own browser:
Authentication. An asset behind a login, a VPN, an IP allowlist, or a signed URL that has since expired.
Content-Type header. Your server serves application/octet-stream for everything, or guesses wrong. The file is fine; the header is what Meta reads.
Redirects. A CDN or shortener that 302s to the real asset. Serve it directly.
Reachability and latency. A slow or geo-restricted origin can time out on the fetch even though the file is perfectly valid.
The test that matters is fetching the URL from outside your network with no cookies and no auth, and inspecting the returned Content-Type header — not opening it in a logged-in browser tab.
Media IDs expire
An uploaded media ID is a short-lived handle, not a permanent asset reference. Three patterns fail:
- Caching an ID for weeks and reusing it across a long campaign
- Using an ID uploaded under a different phone number
- Using an ID from an upload that reported success but was truncated
Upload as part of the send flow, or refresh IDs on a schedule shorter than their lifetime. Do not store one alongside a product record as though it were a permanent URL.
Where 131053 Sits Among Its Neighbours
Code | Meaning | What it points at |
|---|---|---|
131053 | Media upload error | The asset or its fetch |
Parameter value not valid | A malformed media | |
Required parameter missing | The media object omitted entirely | |
Something went wrong | Sometimes surfaces a media problem as an unclassified 500 | |
Message undeliverable | Sometimes an outdated client that cannot render the media |
That last row is worth a note. If a media message fails for a small subset of recipients while succeeding for most, the asset is probably fine and you are looking at error 131026 and an outdated client rather than an upload problem. Media that is genuinely invalid fails for everyone.
Templates with media headers add their own layer: if the template is the problem rather than the asset, you will see error 132000 for a component count mismatch or error 132012 if the media parameter was supplied as a plain string where a structured object was expected.
Frequently Asked Questions
What causes WhatsApp error 131053?
WhatsApp could not upload the media in your message. Meta documents it as "Media upload error" with HTTP status 400 and recommends inspecting the file to confirm it matches supported types and verifying the MIME type. In practice the leading cause is a declared MIME type that does not match the file's actual contents, followed by problems fetching a hosted URL.
Why does my supported file format still fail?
Because the declared type and the real contents disagree. A file named .jpg that is actually a PNG, or a .png exported as WebP, is a supported format with the wrong label, and WhatsApp validates the label against the bytes. Detect the type server-side from the file's magic bytes rather than trusting its extension, then declare what you detected.
Should I use uploaded media or a hosted link?
Upload for anything you send more than once. Uploading validates the file before the campaign runs and gives you one asset instead of thousands of fetches against your origin. Hosted links add an HTTP fetch that can fail on authentication, Content-Type headers, redirects, or reachability — none of which are visible when you open the URL in your own browser.
Why did a media ID that worked yesterday stop working?
Media IDs are short-lived handles rather than permanent references. An ID cached for weeks, uploaded under a different phone number, or produced by an upload that silently truncated will all fail. Upload as part of the send flow, or refresh IDs on a schedule shorter than their lifetime.
My media message fails for some recipients but not others. Is that 131053?
Probably not. Media that is genuinely invalid fails for everyone. A partial failure pattern more often points at error 131026, where an outdated WhatsApp client cannot render the message type. Test by resending the same content as plain text to a failing recipient — if that delivers, the client is the constraint, not your asset.
Detect the Type, Prefer the Upload
Error 131053 has a reputation for being about unsupported formats, and it mostly is not. It is about labels that disagree with contents, and about hosted URLs that behave differently for Meta's fetcher than for a logged-in browser tab.
Two changes remove most of it. Detect MIME type from file bytes server-side and declare what you actually found. And upload media to get an ID rather than passing a link, for anything sent more than once, so validation happens before your campaign rather than during it.
Want media handling that validates before the campaign runs? Helo.ai is a Meta Partner and Google RCS Anchor Partner of the Year, managing media upload, type validation, and ID lifecycle for enterprise WhatsApp programmes. Talk to an expert.
Next: error 131009 if the media identifier itself is being rejected, or error 132012 if a media parameter inside a template is the problem.
