When you share a link on WhatsApp, the app fetches your page, reads a handful of meta tags from the HTML, and assembles a preview card — title, description, and image — before the recipient even taps the link. Get those tags wrong and the preview silently disappears. This guide covers exactly which Open Graph tags WhatsApp reads, why og:image must use an absolute URL, what image dimensions actually work, and how to test and fix previews before you hit send.
How WhatsApp reads link previews
Every time someone pastes a URL into a WhatsApp chat, the app's internal crawler — sometimes called the WhatsApp Link Preview Bot — makes an HTTP GET request to that URL. It parses the HTML response looking for `<meta property="og:...">` tags in the `<head>`. If it finds the right tags, it assembles a preview card. If it doesn't, the link appears as plain text with no visual context.
WhatsApp is not the only crawler that works this way — Facebook, LinkedIn, Slack, Telegram, iMessage, and Twitter/X all follow the same Open Graph protocol developed by Facebook in 2010. The spec lives at ogp.me and defines a set of `<meta>` tags that any website can add to control how its pages appear when shared on social platforms.
When does the crawl happen?
WhatsApp crawls a URL when you first paste it into a chat and the preview loads. The result is aggressively cached — WhatsApp will serve the same preview card for days or even weeks after the initial fetch. This is why updating your OG tags on the server does not immediately fix a broken preview; the cached version keeps appearing. More on cache-busting in a later section.
Note
Previews in group chats vs. direct messages
WhatsApp generates previews in both direct messages and group chats. The behaviour is identical — the same OG tags are used in both contexts. However, there is one nuance: if the sender has disabled link previews in their WhatsApp settings (Settings → Chats → Generate Link Previews), previews will not appear regardless of how correctly your tags are configured. This is a client-side setting, not a server-side issue.
og:image absolute URL requirement
This is the single most common cause of broken WhatsApp previews: a relative path in the `og:image` tag. The Open Graph protocol specification is unambiguous about this — `og:image` must be a full absolute URL. Not a root-relative path, not a protocol-relative URL, not a path fragment. A complete URL with scheme, domain, and path.
| Format | Example | Works in WhatsApp? |
|---|---|---|
| ✓ Absolute URL (correct) | https://yourdomain.com/images/share.jpg | ✓ Yes |
| ✗ Root-relative path | /images/share.jpg | ✗ No — silently fails |
| ✗ Protocol-relative URL | //yourdomain.com/images/share.jpg | ✗ Unreliable |
| ✗ Relative path | images/share.jpg | ✗ No |
| ✗ Data URI | data:image/jpeg;base64,... | ✗ No |
Structured properties can be specified by putting a colon after the property name and using another `og:image` tag with an absolute URL.
Why relative paths fail silently
When WhatsApp's crawler fetches your page, it parses the HTML in isolation — it does not "know" your base URL the same way a browser does. A relative path like `/images/share.jpg` has no context, so the crawler either ignores it or attempts to resolve it against a base URL it may not have correctly inferred. The result is a missing image with no error message — the preview either appears without an image or doesn't appear at all.
Always use the full absolute URL including `https://`. If your site supports both HTTP and HTTPS, always use `https://` — many social crawlers refuse to load non-HTTPS images in previews for security reasons.
Warning
CDN and third-party image hosts
If your images are served from a CDN or a third-party host (like Cloudinary, Imgix, or a cloud storage bucket), the absolute URL requirement still applies — just use the CDN's full URL. The only additional consideration is CORS headers: make sure your CDN allows cross-origin requests, since some crawlers check this. Also verify that the CDN URL doesn't have authentication tokens that expire — a time-limited signed URL will break previews for anyone clicking the link after the token expires.
Open Graph Preview Text Optimizer
Check whether your og:title and og:description lengths are optimized for WhatsApp, Facebook, LinkedIn, and Twitter simultaneously.
og:image size and format rules
Getting the image URL right is only half the battle. WhatsApp also has size and format requirements that determine whether the image is displayed prominently or skipped entirely.
Recommended dimensions
The Open Graph spec recommends 1200×630 pixels at a 1.91:1 aspect ratio. This is the target that renders well across WhatsApp, Facebook, LinkedIn, and Slack simultaneously, so there is no reason not to use it as your default.
| Platform | Minimum size | Recommended size | Aspect ratio |
|---|---|---|---|
| 300×200 px | 1200×630 px | 1.91:1 | |
| 200×200 px | 1200×630 px | 1.91:1 | |
| 200×200 px | 1200×630 px | 1.91:1 or 1:1 | |
| Twitter/X | 280×150 px | 1200×628 px | 2:1 (summary_large_image) |
| Slack | 500×300 px | 1200×630 px | 1.91:1 |
WhatsApp will display images down to around 300×200 pixels, but anything smaller tends to be rendered as a tiny thumbnail rather than a prominent image, and very small images may be omitted entirely. Images below the minimum threshold or with extreme aspect ratios (very tall portrait images, for example) are sometimes rejected.
Supported file formats
- JPEG (.jpg, .jpeg) — Best choice for photographs and images with gradients. Widely supported by all social crawlers.
- PNG (.png) — Best choice for graphics, logos, and images with transparency. Also universally supported.
- WebP — Mixed crawler support. Avoid using WebP for og:image even if your site otherwise uses WebP images.
- GIF — Widely supported but only the first frame is shown (no animation). Rarely ideal for preview images.
- SVG — Not supported by most social crawlers including WhatsApp. Use a rasterised PNG or JPEG instead.
File size considerations
Keep your `og:image` file under 300 KB. WhatsApp's crawler runs on Meta's servers and is optimised for speed — very large images take longer to fetch and increase the chance of a timeout, resulting in a preview with no image. A well-optimised JPEG at 1200×630 px should comfortably fit under 200 KB.
Tip
Common reasons previews break
Even with correct OG tags in place, WhatsApp link previews sometimes fail to render. These are the most frequent causes.
Relative og:image URL
Already covered above, but worth repeating because it's the most common mistake. Always use `https://yourdomain.com/path/to/image.jpg` — never `/path/to/image.jpg`. Use the OG Tag Validator to catch this before sharing.
OG tags rendered by JavaScript (not in server-rendered HTML)
WhatsApp's crawler does not execute JavaScript. If your meta tags are injected by a client-side framework after the page loads — common in single-page applications built with React, Vue, or Angular without server-side rendering — the crawler will see an empty `<head>` and generate no preview. OG tags must be present in the initial HTML response from the server. Use server-side rendering (SSR) or static site generation (SSG) to ensure the tags are in the raw HTML.
Server blocking the WhatsApp crawler
Security tools like Cloudflare's Bot Fight Mode, custom WAF rules, or aggressive robots.txt configurations sometimes block the WhatsApp crawler. Check your `robots.txt` to ensure it isn't blocking all crawlers with `User-agent: * Disallow: /`. Also check your server's security logs when testing — you may find the crawler being blocked with a 403 or 429 status.
og:image returns a non-200 status
If the image URL returns a 404, 403, 301 redirect, or any non-200 response, WhatsApp silently drops the image from the preview. Verify that your image URL is directly accessible (no redirects, no authentication required) by opening it in a private browser window and checking the status. Use the HTTP Headers Inspector to check the response headers for any image URL.
og:image hosted on HTTP (not HTTPS)
Social crawlers typically enforce HTTPS for security. An image served over plain HTTP will often be skipped even if the rest of your page is HTTPS. Always ensure your `og:image` URL starts with `https://`.
og:image exceeds the size limit or has an invalid format
Very large images (over 5 MB) or unsupported formats (SVG, WebP in some crawlers) are silently skipped. Stick to JPEG or PNG under 300 KB at 1200×630 px.
Warning
Cache-busting WhatsApp previews
WhatsApp caches link previews per URL. Once a URL has been crawled, the same preview is served to all recipients who receive that link — regardless of whether you've updated the OG tags since. The cache lifetime is not publicly documented, but in practice it can persist for several days to a week.
The query string method
The most reliable workaround is to append a query string to the URL when you share it. WhatsApp treats `https://yourdomain.com/page?v=2` as a distinct URL from `https://yourdomain.com/page`, so it will re-crawl the page fresh and generate a new preview. The query string can be anything — `?v=2`, `?ref=wa`, `?share=1` — as long as it's different from what was shared before.
Tip
Using Facebook's Sharing Debugger to warm the cache
Facebook's Sharing Debugger (developers.facebook.com/tools/debug) is a tool that both validates your OG tags and forces a re-scrape of your URL on Meta's infrastructure. Since WhatsApp and Facebook share the same Open Graph infrastructure under Meta, scraping via the Sharing Debugger can sometimes prime (or clear) the WhatsApp preview cache for the same URL. It's worth running after any tag change alongside the query string method.
Summary: cache-busting workflow
- Update your OG tags on the server and verify the raw HTML response contains the new values.
- Run your URL through the OG Tag Validator to confirm the tags are correct.
- Submit the URL to Facebook's Sharing Debugger to force a re-scrape.
- When sharing on WhatsApp, append a new query string (e.g., `?v=2`) to ensure a fresh crawl.
Advanced OG tag patterns
Once you have the basics working, a few advanced patterns give you more control over how your content appears on WhatsApp and other social platforms.
Multiple og:image tags
The Open Graph spec allows multiple `og:image` tags on a single page. Each additional image tag is treated as an alternative — crawlers typically use the first valid image they encounter. This is useful for providing a fallback:
<!-- Primary: large landscape (WhatsApp, Facebook, LinkedIn) -->
<meta property="og:image" content="https://yourdomain.com/share-1200x630.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<!-- Fallback: square (some LinkedIn contexts, Instagram) -->
<meta property="og:image" content="https://yourdomain.com/share-1200x1200.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="1200" />Using og:image separately from twitter:image
Twitter/X reads `twitter:image` first and only falls back to `og:image` if no Twitter Card tags are present. This means you can specify a different image for Twitter without affecting WhatsApp. Twitter's recommended image size for a `summary_large_image` card is 1200×628 px (2:1 ratio) rather than 1200×630 px. The difference is small, but if you want pixel-perfect rendering on both platforms, specify both:
<!-- Used by WhatsApp, Facebook, LinkedIn, Slack -->
<meta property="og:image" content="https://yourdomain.com/share-1200x630.jpg" />
<!-- Used by Twitter/X specifically -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://yourdomain.com/share-1200x628.jpg" />Dynamic OG images
Many modern sites generate OG images dynamically — for blog posts, product pages, or user profiles — using services or server-side rendering. If you're generating images programmatically, remember that the URL must still be absolute and publicly accessible. Dynamic OG image URLs often look like: `https://yourdomain.com/api/og?title=My+Post+Title` — this is perfectly valid as long as the endpoint returns an actual image with the correct `Content-Type` header (`image/jpeg` or `image/png`), not an HTML page.
Validating structured data alongside OG tags
Open Graph tags work alongside (not instead of) JSON-LD structured data. For articles, products, and local businesses, structured data enables Google rich results while OG tags handle social sharing previews. The two systems are complementary — you need both. Use the Structured Data Validator to check your JSON-LD schema while the OG Tag Validator handles your Open Graph implementation. The Meta Tag Generator can produce a complete `<head>` section with both OG tags and Twitter Card tags in one output.
Complete recommended head section
For reference, here is a complete, production-ready `<head>` section covering Open Graph (WhatsApp, Facebook, LinkedIn), Twitter Card, and standard SEO meta tags:
<head>
<!-- Standard SEO -->
<title>Your Page Title | Site Name</title>
<meta name="description" content="A concise 150-160 character page description." />
<link rel="canonical" href="https://yourdomain.com/your-page" />
<!-- Open Graph (WhatsApp, Facebook, LinkedIn, Slack) -->
<meta property="og:type" content="website" />
<meta property="og:url" content="https://yourdomain.com/your-page" />
<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A concise summary for social sharing." />
<meta property="og:image" content="https://yourdomain.com/images/share-1200x630.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Descriptive alt text for the preview image." />
<meta property="og:site_name" content="Your Site Name" />
<meta property="og:locale" content="en_US" />
<!-- Twitter Card (Twitter/X) -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Your Page Title" />
<meta name="twitter:description" content="A concise summary for Twitter." />
<meta name="twitter:image" content="https://yourdomain.com/images/share-1200x628.jpg" />
</head>Meta Tag Generator
Generate a complete set of Open Graph, Twitter Card, and SEO meta tags in one go — no manual writing required.
Key takeaways
- WhatsApp reads four Open Graph tags to build a link preview: og:title, og:description, og:image, and og:url.
- og:image must be a full absolute HTTPS URL — relative paths silently fail in WhatsApp and all other social crawlers.
- Use 1200×630 px JPEG or PNG under 300 KB as your og:image for best cross-platform rendering.
- Include og:image:width and og:image:height tags so crawlers can lay out the preview before the image loads.
- OG tags must be in the server-rendered HTML — JavaScript-injected meta tags are not read by WhatsApp.
- WhatsApp caches previews per URL for days. Append a query string (?v=2) when sharing an updated link.
- Use the OG Tag Validator to check all tags before sharing, and Facebook's Sharing Debugger to force a re-scrape after changes.