Rich media on WhatsApp: images, video, PDFs and limits

WhatsApp supports images, video, audio, documents and stickers alongside text. For a business the practically important types are images, video and documents, and each carries a maximum file size along with a list of accepted formats.

The size ceilings are where most problems occur, and they differ by media type — documents are permitted to be considerably larger than images or video. Meta publishes the current figures, and they have been revised over time, so a business designing a workflow around a specific number should read the documentation rather than rely on a remembered value or on what happened to work last year.

What is worth internalising instead is the failure mode. A file that exceeds the limit does not arrive in a degraded form; the send fails. A wholesaler whose fabric catalogue has grown steadily as pages were added will one day find it does not send, with no change in how it was prepared. The fix is compression or splitting, and knowing to check the file size before wondering whether the recipient's number is wrong saves a lot of confusion.

Format matters too. Sending a file in an unusual format may technically succeed and then be unopenable on the recipient's phone, which is a worse outcome than a clean failure because the business believes it succeeded.

The most common media failure in Indian small business messaging is a catalogue document that has become too large, and it is almost always caused by the images inside it rather than the document itself.

A PDF assembled from photographs taken on a modern phone carries images sized for print at a resolution far beyond anything a phone screen can display. Twenty such pages produce a file many times larger than it needs to be to look identical on the device where it will be read. Compressing the images inside the document typically reduces the file size dramatically with no perceptible loss on a phone.

Splitting is the other approach, and it is often better for reasons beyond file size. A single large catalogue asks the recipient to download everything and then find the relevant part. Several smaller documents organised by category — one per fabric type, one per product range — let the business send only what the customer asked about. That is both a smaller file and a more useful reply.

A third option is to send a link rather than a file. This shifts the size problem elsewhere, keeps the document updatable after sending, and lets the business change the content without resending. The trade-off is that a link requires the recipient to have a connection at the moment they open it, whereas a downloaded document is available afterwards regardless — which matters for customers on intermittent connections.

Media type should follow from what the customer needs to do with the information, not from what is easiest to produce.

An image suits a single thing the customer needs to see: one product, one colour, one item of stock. It loads immediately, displays inline without a download, and requires no decision from the recipient. For a customer asking whether something is available, an image is the answer.

A document suits information that is structured, lengthy, or meant to be kept: a price list, a specification sheet, a quotation, an invoice. The distinguishing property is that a document can be saved, forwarded internally and referred back to. A customer who needs to show a price list to a colleague is better served by a document than by fourteen images.

Video suits things that only make sense in motion: how a mechanism operates, how a fabric moves, how a product is assembled or installed. It is a poor choice for information that is really a list, because the viewer cannot scan it, cannot skip to the relevant part easily, and cannot extract a figure from it without watching again.

The common error is defaulting to whatever the business already has. Sending a printed brochure photographed page by page produces images of a document, which is the worst of both — not scannable like a document, not immediate like an image.

Media behaves differently inside a template than in a free-form conversation, and confusing the two causes avoidable problems.

Inside an open customer service window, a business sends media as an ordinary session message. No approval is involved: a customer asks about an item and the business sends a photograph, exactly as anyone would.

Outside the window, media has to travel inside an approved template. Templates support a media header — an image, a video or a document at the top of the message — and the header type is fixed at approval time. A template approved with an image header sends an image; it cannot be used to send a document instead. A business needing to send both must have both templates approved.

This has a scheduling consequence familiar from templates generally. A business that discovers, mid-campaign, that it needs a document-header template it does not have is waiting on a review cycle. Anticipating which media types will be needed outside a live conversation, and getting those templates approved in advance, avoids the wait.

Authentication templates are the exception in the other direction: they permit no media at all, along with no URLs and no emojis. That restriction is absolute and enforced automatically, so a verification message cannot carry an attachment however useful it would be.

A business sending media sees a file leave. The recipient's experience is different in ways that affect whether the message works at all.

Media consumes the recipient's mobile data, and many customers are on limited plans and variable connections. A large video sent to someone who did not ask for it is spending their money, and repeated unrequested media is a reason people mute or block a business. This is a real cost the sender does not see.

Downloads may not be automatic. Depending on the recipient's settings, media waits for a tap, and on a slow connection that tap leads to a spinner. A customer who needs a price to make a decision, and is waiting on a download, may simply stop.

Storage matters too. Media saved to the phone accumulates, and a business that sends large files routinely becomes the reason someone's storage is full — which is a specific and memorable kind of irritation.

The practical conclusions are modest but worth applying. Send media the customer asked for, or that clearly serves them, rather than as a default. Compress before sending, since a file that looks identical on a phone at a fraction of the size costs the recipient less. And put the essential information in the text as well as the media, so a customer who cannot or will not download still gets the answer.

Check the file size before sending anything at volume, particularly documents that have been edited repeatedly. Files grow as pages and images are added, and the send that fails is usually the one after the edit nobody thought about.

Compress images inside documents rather than compressing the document as a whole, since that is where the size is. Keep a phone-sized version of any catalogue that gets sent often, separate from the print-quality original, and remember to update both when prices change — a stale compressed copy sending out old prices is a worse problem than a large file.

Name documents so the filename means something on the recipient's device. A file called "final_v3.pdf" sitting in someone's downloads is unidentifiable a week later; one named for the business and the content is findable.

Test on a real phone over a mobile connection rather than on a desktop over office broadband, because that is the environment the customer is in.

And put the key information in the accompanying text. A photograph of an item with no price in the message text produces the same follow-up question every time, and a document sent with no explanation of what it contains often goes undownloaded. The media carries the detail; the text should carry the point.