You paste a link into a WhatsApp group and hit send. The message goes out with nothing attached: no image, no title, just the raw URL sitting there in blue. You try the same link from your laptop on WhatsApp Web and the card renders perfectly, picture and all.
Same link. Same tags on the page. Two different results, and no tool anywhere that will tell you why.
The reason is that WhatsApp doesn't have one crawler. It has three, and the one that fetched your link was the phone in your hand.
The User Agent Tells You Which Device Fetched It
Meta documents the crawler's user agent as WhatsApp/2.x.x.x A|I|N, where the trailing letter stands for Android, iOS, or web. That letter isn't decoration. It's there because the fetch originates from the sender's platform: on mobile, the device composing the message makes the HTTP request to your page directly, while WhatsApp Web hands the job to Meta's servers. Meta's link preview requirements spell out the format.
Once you know that, a whole category of WhatsApp bug report stops being mysterious. A preview that fails on one person's phone and works on another's isn't a caching quirk. It's two different clients on two different connections, each doing its own fetch, each free to give up at a different moment. Your office wifi resolves your CDN in 80 milliseconds. Someone on a train does not.
600KB Is the Number That Breaks Most Previews
Meta's documentation states it plainly: the image should be under 600KB. That is the strictest image budget of any major platform by a wide margin. Facebook accepts several megabytes. So does X. A hero image exported at full quality from a design tool routinely lands between 1MB and 3MB, which means the exact file that renders everywhere else produces nothing at all here.
Nothing is the operative word. There's no warning, no error, no fallback thumbnail. The card arrives without a picture, and because the title and description still come through, it reads as a partial success rather than a failed requirement. If one platform and only one platform is dropping your image, check the file size before you check anything else. Our guide to Open Graph image sizes covers what to export for each destination.
The Dimension Rules Are Looser Than the Advice You've Read
Meta asks for an image at least 300px wide with a width-to-height ratio of 4:1 or narrower. That's considerably more permissive than the 1200 × 630 that every guide recommends, and it means WhatsApp will render shapes Facebook would demote to a small thumbnail.
Don't read that as permission to ship a 300px file. It clears the minimum and still looks soft in the large card WhatsApp uses for one-to-one chats. Where the rule actually bites is on wide banner crops: a 1600 × 200 header strip is 8:1, fails the ratio test, and gets dropped even though it's comfortably under the file size limit.
Your Tags Have to Fit in the First 300KB of HTML
Buried in the same documentation is a requirement almost nobody repeats: the head section carrying your tags must appear within the first 300KB of the HTML. WhatsApp reads the top of the document and stops.
That sounds like an enormous budget until you look at what modern frameworks put above your metadata in the source. Inlined critical CSS, a preloaded font stack, a base64 hero image, a tag manager snippet, a JSON blob of server-rendered state. Any of these can sit between the opening of <head> and your og:image. On a page that ships 400KB of inline styles before the first meta tag, the crawler never reaches your metadata. The page is fine. The tags are correct. WhatsApp just stopped reading before it got there.
This is also why client-rendered tags never work. If a framework injects og:title after hydration, there's nothing in the HTML response to find, and WhatsApp doesn't run JavaScript to go looking. Meta lists og:title, og:description, and og:url as required and specifies they must be inside <head> and non-empty. The one people skip is og:url, which is worth understanding properly because it's the tag most platforms key their cache on. We explain what each Open Graph tag does if you want the full set.
Ten Seconds, Then It Gives Up
Meta's documentation says that if no preview appears within about ten seconds of composing the message, the requirements haven't been met. That ten seconds covers everything: DNS, TLS, any redirects, the HTML response, and the image fetch. Three redirects on a cold cache can eat most of it before your page is even reached. Test a link the way it will actually be shared, on a phone over cellular, not on a wired connection at your desk.
There Is No Debugger, and the Cache Isn't Where You Think
Facebook has the Sharing Debugger. LinkedIn has Post Inspector. WhatsApp has neither. There's no official tool that shows you the card before you send it, and no button that purges a stored copy.
Search for how long WhatsApp caches a preview and you'll find confident answers ranging from 24 hours to 72 hours to several weeks, which is a good sign the question itself is wrong. On WhatsApp Web the fetch is server-side, so there's a server-side cache to argue about. On mobile there mostly isn't one to reach. The preview is generated by the sending device and travels attached to the message, which means that once the message is delivered, the card in that thread is frozen. Editing the destination page doesn't touch it. Neither does waiting.
That's a meaningfully different failure from every other platform. On X, a wrong card is stale for up to seven days and then corrects itself. On WhatsApp, a wrong card sent to a group of two hundred people is wrong in that thread permanently, for everyone in it. We went through what each platform caches and which ones you can actually purge in more detail. WhatsApp is the one where the answer is simply no.
Check It Before You Send, Because There Is No After
With no debugger, verification has to happen against the page itself. Fetch the URL, read what a crawler would read, and confirm it against WhatsApp's specific limits rather than the generic 1200 × 630 advice:
- og:title, og:description, and og:url are present, non-empty, and inside <head>.
- og:image is an absolute https:// URL, under 600KB, at least 300px wide, and no wider than 4:1.
- The tags appear early in the HTML source, not after a large inline stylesheet or state blob.
- The whole page, redirects included, responds well inside ten seconds on a slow connection.
Prelinq's Open Graph checker fetches the page live on every request and holds no cache of its own, so it shows you the tags a crawler receives right now. It's the closest thing to a WhatsApp debugger that exists, which says more about the gap than about the tool.
All of this assumes the page is yours to fix. Most links people send in a chat aren't: an affiliate offer, a partner's landing page, a news article, a product page on a store you have no login for. You can measure exactly how broken the preview is and have no way whatsoever to change it, a problem we've written about at length.
Prelinq moves the metadata onto a page you do control. You build the card, pick the title, description, and image, and share a Prelinq link that carries those tags and forwards whoever clicks through to the original destination. The image is served from our storage, so the 600KB ceiling and the absolute-URL requirement are handled for you. The tags sit at the top of a small HTML document, so the 300KB budget is never a question.
Be clear about what that does and doesn't solve. It won't repair a message you've already sent. Nothing will, on WhatsApp. What it does is make the first send correct, which on the one platform with no undo is the only thing that counts. Two active links are free, so you can build the card and see it rendered across every platform before it leaves your hands.