Can an Open Graph image be a WebP file?
Yes, Open Graph markup can point to a WebP image. Whether a social platform displays it depends on that platform’s crawler, so test your actual previews.
Yes, at the Open Graph markup level. The protocol lets og:image point to an image URL and provides optional metadata for its MIME type; it does not list permitted image formats or exclude WebP. But that does not guarantee every social network or messaging app can decode and display WebP. Each crawler makes that choice.
If a preview must work across several platforms, test the actual destinations. Where WebP support is undocumented or uncertain, use a format you have confirmed works for those audiences, or maintain a tested platform-specific approach.
1. What Open Graph does and does not guarantee
The Open Graph Protocol defines og:image as the image URL representing a page or object. Its optional og:image:type property identifies the image MIME type. The protocol does not specify a format allowlist, so a WebP URL served as image/webp fits its metadata model. That is a conclusion about the markup standard, not a promise about any crawler’s decoder. See the Open Graph Protocol specification.
The distinction matters: valid metadata can still produce a missing image if a platform cannot fetch, inspect, or decode the resource. Platform documentation and live preview behavior determine practical compatibility.
2. Add WebP Open Graph metadata
Put the tags in the document’s <head>. Use an absolute, publicly fetchable image URL and make the MIME type and dimensions match the actual file.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta property="og:title" content="A page worth sharing">
<meta property="og:description" content="A short description of the page.">
<meta property="og:url" content="https://example.com/article">
<meta property="og:type" content="website">
<meta property="og:image" content="https://example.com/share-card.webp">
<meta property="og:image:type" content="image/webp">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A blue illustration of a page being shared">
</head>
<body>...</body>
</html>
og:imageis the image URL. Use the complete HTTPS URL rather than a path relative to the page.og:image:typeis optional, but if present should describe the actual served file:image/webpfor WebP.og:image:widthandog:image:heightare optional dimensions. Keep them accurate; the example values are not universal requirements.og:image:altshould describe the image for people who cannot see it. The protocol recommends supplying it when an image is set; it is not a caption.
The Open Graph specification permits multiple values for properties such as og:image and prefers the first tag in a conflict. It does not promise that a consumer will try the next image when it cannot decode the first one. Multiple tags alone are therefore not a reliable WebP fallback mechanism.
3. Check the served image and platform requirements
- Confirm the response. The image URL should be reachable without a login, browser session, or restrictive hotlink rule. Its HTTP response should return the WebP bytes and a matching
Content-Type: image/webpheader. - Check dimensions and file size. Choose dimensions and file size that suit the destination, while keeping the image visually clear. A valid Open Graph tag does not override a platform’s own limits.
- Inspect the page source. Confirm the tags are in the server-rendered HTML head that a crawler receives. If the tags appear only after client-side JavaScript runs, verify that the target crawler executes that JavaScript before relying on it.
- Test each important destination. Share the URL or use that service’s preview/debugging workflow, then check the image actually displayed. Record the result by platform and retest after changing the image URL or metadata.
For LinkedIn, its guidance for the sharing module specifies a maximum image size of 5 MB, minimum dimensions of 1200 × 627 pixels, and a recommended 1.91:1 ratio. That section does not state whether WebP is accepted. The JPG, PNG, or GIF list on the same help page is for single image ads, not organic shared-link previews. Do not apply that ad rule to link previews. See LinkedIn’s image specifications.
4. Choose a format and fallback strategy
| Decision | Practical approach |
|---|---|
| WebP support is documented or verified for every important destination | Serve WebP, use accurate MIME metadata, and keep checking actual previews. |
| Support is unclear for one or more destinations | Use a format confirmed on those destinations, or test a platform-specific fallback before depending on it. |
| You want to list WebP and another image in metadata | Do so only as metadata; do not assume a crawler will retry a later image after a decoding failure. |
Compare formats against crawler compatibility, image appearance, transparency needs, file size, and delivery constraints. There is no protocol-level answer that settles the platform question for every service. The Open Graph specification defines the metadata model; the destination’s own documentation and preview determine whether its implementation accepts a particular file.
5. Troubleshooting missing or stale previews
| Symptom | Likely cause | What to check or change |
|---|---|---|
| No image appears | The crawler cannot fetch the image, cannot decode its format, or does not see the metadata. | Open the absolute image URL without a session, inspect its status and Content-Type, confirm the tags are in the returned HTML head, and test a known-compatible format on that platform. |
| The image URL loads in a browser but not in a preview | The browser may have cookies or capabilities the crawler lacks; access rules, redirects, or server responses may differ. | Check the unauthenticated response and redirect chain. Make the image publicly fetchable by the crawler and serve the correct bytes and MIME type. |
| A different or old image appears | The page or image may be cached by the platform. | Use the platform’s preview inspection or refresh process where available. For a changed asset, publish it at a new URL and update the metadata; verify the new preview. |
| Metadata says WebP but the resource is another format | The declared MIME type does not match the served file. | Correct og:image:type or the server response so each describes the real resource. |
| LinkedIn preview is rejected or cropped unexpectedly | The image may exceed the sharing module’s size limit or miss its stated dimensions or ratio. | For shared links, check the 5 MB maximum, 1200 × 627 pixel minimum, and recommended 1.91:1 ratio in LinkedIn’s sharing image guidance. Its ad format list is a separate requirement. |
Adding a second og:image did not fix it |
The platform may select the first image, and the protocol does not require retrying another image after decode failure. | Put the image you intend the consumer to use first, then test. For uncertain destinations, choose a verified format rather than assuming fallback. |
6. Performance, reliability, and cost
For this decision, the main operational tradeoff is compatibility versus image delivery. A smaller file can reduce transfer size, but it is useful only if the destination can decode it and the result retains the visual quality you need. Keep the asset under documented platform limits, make it reliably accessible, and test the rendered preview. The sources cited here establish LinkedIn’s sharing-image limit and dimensions but do not establish a universal WebP support matrix, benchmark, or cross-platform cost difference.
When investigating what a crawler receives, a screenshot can help inspect a page’s rendered appearance, but it does not prove that a social platform accepts its image format or that the platform’s cached preview has refreshed. ScreenshotNeo is a website screenshot API and MCP server for developers; its browser capture is useful for visual checks, while destination-specific preview testing remains necessary.
7. Or skip the browser setup
To capture a page while checking its rendered appearance, make one API request. See the ScreenshotNeo documentation for API options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/article -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com/article"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com/article'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
- Cookie banners, popups, and chat widgets are removed before the shot.
- Bot checks, blank pages, and failed loads are never billed; response headers report the page verdict and billing status.
- An MCP server lets AI agents use screenshot, page-info, and PDF capture tools.
- 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.
Sign up for 1,000 free screenshots a month, with no card required.
8. FAQ
Does the Open Graph specification explicitly mention WebP?
It defines an image URL and optional MIME-type metadata, without an image-format allowlist. That supports WebP at the markup level, not as a guarantee about consumer support.
Does LinkedIn’s JPG, PNG, or GIF list apply to organic link previews?
No. That list is for single image ads. LinkedIn’s sharing module section gives size and dimension guidance but does not state accepted file types.
Will two og:image tags guarantee a fallback?
No. The protocol allows multiple images and describes ordering for conflicts; it does not specify retry behavior when an image cannot be decoded.
What should I do if WebP support is uncertain?
Test on the destinations that matter. Use an image format confirmed for any audience where a missing preview would be a problem.


