Comparisons
Best Format for Google Discover and Social Previews
Images used in Discover and social previews need to look strong in a small card while staying efficient enough for mobile-heavy distribution.
The short answer
For many site-controlled preview images, WebP is a strong default because it keeps share assets lighter while preserving quality well.
The preview image is a distribution asset
A Discover or social-preview image is not only part of the page. It is part of distribution. That means the format needs to support quick loading, clean framing, and trustworthy visual quality in feeds and cards. WebP is often a strong web-facing choice, while JPG remains useful when the pipeline or downstream platform still expects it more comfortably.
The image also needs the right dimensions and crop. Format alone cannot solve a poor preview.
- WebP for many web-facing share images and card previews.
- JPG for compatibility-led preview workflows.
- PNG when text overlays or graphic edges need extra clarity.
Real examples
A news-style card image reused on mobile-heavy traffic sources. A tutorial preview with large overlaid text that may need a sharper export. A branded campaign image that needs to survive both site use and social sharing.
How it affects SEO and page speed
Preview images affect click behavior, distribution quality, and page efficiency when they are reused on the site itself.
Developer and workflow notes
Preview image workflows should be standardized so articles do not ship random crops, formats, or dimensions.
Common mistakes to avoid
- Reusing a giant hero image without checking the preview crop.
- Ignoring mobile feed rendering when preparing the asset.
- Using a heavy format with oversized dimensions for every share image.
- Treating preview images as an afterthought instead of a distribution asset.
Exact dimensions for each card slot
One 1200x630 px asset at a 1.91:1 ratio is the single image that renders correctly across Facebook, X, LinkedIn, Slack, and Discord, so build that file first and treat everything else as a variant. The trap is Google Discover: it requires a minimum width of 1200 px and more than 300,000 total pixels, and it prefers 16:9 (1.91:1 is wider and gets letterboxed in the Discover feed), so a single OG file alone will not earn the large Discover card. Export a second 1200x675 px (16:9) version specifically for the in-article image Discover pulls.
Crop each variant to its own frame rather than scaling one master down. Resize Image handles the pixel target, and Crop Image fixes the framing so faces and logos survive the tighter ratios.
- Open Graph master (Facebook, LinkedIn, Slack, Discord): 1200x630 px, 1.91:1.
- X summary_large_image: 1200x628 px, 1.91:1, hard cap 5 MB; below 300x157 px X drops the card entirely.
- LinkedIn link preview: 1200x627 px; smaller files get upscaled and go soft.
- Facebook: 1200x630 px; under 600 px wide it falls back to a tiny square thumbnail instead of the inline card.
- Google Discover in-article image: 1200x675 px (16:9), minimum 1200 px wide and over 300,000 total pixels.
File-size and quality targets that survive re-encoding
Every platform re-encodes the image you supply, so your export quality is a starting budget, not the final result. Ship a 1200x630 JPG at quality 80 to 85, which lands a typical photographic preview between 80 and 180 KB. Keep it under 300 KB; past that, the platform compresses harder on its second pass and gradients band. WebP at quality 75 to 80 hits roughly the same visual result at 30 to 45 percent fewer bytes, which is why it is the better default for the copy you host and reuse on the page itself.
Reserve PNG for previews built around flat color, sharp text overlays, or a logo on a solid field, where 8-bit JPG artifacts show as halos around the letterforms. A text-heavy 1200x630 PNG-8 often beats the JPG on both clarity and size. Skip AVIF for the social file specifically: as of 2026 several scrapers still fail to render it in the preview crawl and fall back to no image. Use Compress Image to pull any export down to its target weight after the dimensions are locked.
Make the image eligible, not just present
Discover never serves a large card unless the page carries the directive max-image-preview:large, set either in the robots meta tag or the X-Robots-Tag HTTP header. Without it Google is capped at a thumbnail no matter how large the source file is, which is the most common reason a high-resolution hero still renders small. Confirm the og:image:width and og:image:height tags state 1200 and 630 so scrapers reserve the correct box before the bytes arrive and the layout does not shift.
Design for the safe zone, because each surface crops differently from the same file. Keep the headline and logo inside the center 1200x600 px band, leaving roughly 15 px of margin top and bottom, so nothing critical is clipped when X trims to 1.91:1 or Discover reframes to 16:9. Verify against the cache, not your editor: run the URL through Facebook's Sharing Debugger and X's Card Validator, then force a re-scrape, since both pin the first image they fetched and will keep serving a stale or wrong crop until you clear it.
Tools that help
Once you have picked a format, finish the job in your browser: convert the file, resize it to the layout you actually need, and compress it to a realistic weight with the tools below.
