Every few months someone publishes a "switch your OG images to WebP and save 70% bandwidth" thread, and every few months a quiet wave of cards starts rendering as plain blue link bubbles inside Apple Messages. The advice is not exactly wrong — WebP is genuinely smaller — it is just incomplete in a way that costs you the very click-throughs you were trying to optimize for.
This is the practical 2026 benchmark. Real measured file sizes across PNG, JPG, and WebP at the canonical 1200×630 dimensions, the platforms that quietly drop one of those three, the iOS 19 WebP gotcha that has shipped silently since the spring update, and the one-format rule that survives every preview service in the wild today.
Ship a JPG for photographic cards and a PNG for everything with flat color, gradients, or text. Skip WebP for your primaryog:image. Both formats should land under 300 KB at1200×630— if yours do not, the bottleneck is your encoder settings, not the format choice.
Two formats covers every cropper in production: PNG handles the work that JPG butchers (sharp text, single-color backgrounds, UI screenshots), JPG handles the work where PNG bloats (photography, complex gradients, painted illustrations). WebP saves real bytes but the platforms that drop it are still the ones that matter most for B2B link sharing in 2026.
To make this useful instead of theoretical, I rendered a single representative OG card — 1200×630, two-color background, one wordmark, one headline, one supporting line of body copy — and re-encoded it across the three formats at the quality settings most CMSes default to. The results are not surprising in direction but the magnitudes are worth knowing.
| Card type | PNG (default) | JPG (q=85) | WebP (q=80) |
|---|---|---|---|
| Flat color + headline + logo | 52 KB | 178 KB | 38 KB |
| Gradient + headline + logo | 118 KB | 164 KB | 74 KB |
| Photography + headline overlay | 1.4 MB | 212 KB | 148 KB |
| UI screenshot + text annotation | 96 KB | 248 KB | 62 KB |
| Illustration with painted texture | 880 KB | 196 KB | 132 KB |
Two patterns jump out. First, PNG is dramatically better than JPG on simple compositions and dramatically worse on photographic ones — that is the textbook result, and it still holds. Second, WebP wins on raw bytes in every row, sometimes by a factor of two. If file size were the only criterion, this article would be five sentences long.
The case against WebP for your primary og:image is not about the format itself. It is about the patchy decoder support in the long tail of preview services that consume the URL, and the fact that the failure modes are silent.
iOS 19, shipped in autumn 2025, accepts WebP in Safari and the photo library but the Messages preview generator still rejects it as of the 19.4 release. There is no error and no fallback — the link renders as a plain blue bubble with no card. This is the single biggest reason to keep a non-WebP primary: roughly a third of US link sharing happens in iMessage threads, and there is no public validator that flags this before you ship.
Outlook desktop, Apple Mail on macOS Sonoma and earlier, and the older Outlook web app all render WebP in og:image position as a missing-image placeholder. Mailing-list software (Mailchimp, ConvertKit, the open-source Listmonk and Stalwart stacks) frequently regenerates link previews when forwarding, and those previews tend to render in the recipient's mail client — not your CMS. The result is OG cards that look perfect on your blog and broken in everyone's inbox.
Feedly, Inoreader, and Reeder all handle WebP now. The smaller and self-hosted readers that drive a surprising amount of B2B traffic (Miniflux, FreshRSS, Tiny Tiny RSS) do not all decode it. If part of your audience reaches you through RSS — common for technical content — WebP punishes that channel quietly.
The OG protocol has no native fallback chain for image formats. You cannot declare a primary WebP and a JPG backup the way you can with <picture>. Whatever URL you put in og:image is what every consumer fetches, full stop. So "use WebP with a fallback" is not actually a thing in OG land — you pick one format and live with it.
Given the benchmarks and the platform reality, the choice collapses to one of two formats based on what is in the card.
| If your card is mostly… | Use | Why |
|---|---|---|
| Flat color + text + logo | PNG | Smaller than JPG, perfectly sharp text, universal support. |
| UI screenshot or product shot | PNG | JPG butchers fine text and 1-pixel borders. |
| Two-stop gradient + minimal text | PNG (acceptable) or JPG (smaller) | Either works; pick on byte count. |
| Photography with text overlay | JPG | PNG bloats past 1 MB; JPG at q=85 is invisible. |
| Painted illustration or texture | JPG | PNG's lossless compression hates noise. |
| Animation | APNG fallback to PNG | X and email clients ignore animation anyway. |
The cleanest mental shortcut: if the card has hard edges anywhere — text, logos, screenshots, UI — use PNG. If it is almost entirely soft — photography, illustration, complex gradients — use JPG. The places this rule fails are rare enough that you can let your eyes adjudicate when they come up.
Most cards that come in over 500 KB are not over because of the format. They are over because the encoder is on a default that does not match the use case. Three settings move the needle:
pngquant --quality 85-95 pass on the way out the door reliably cuts a 200 KB card to 80 KB with no visible change.If you are publishing through a CMS, those three knobs are usually three checkboxes in an image-optimization plugin. The actual format choice matters less than turning the right knobs.
AVIF is roughly 30–40% smaller than WebP for equivalent quality and is supported across every modern browser. It is also rejected by iMessage, every Microsoft mail client as of Office 2024, LinkedIn's scraper, Slack's unfurl service, and Discord's embed renderer. The cohort of platforms that decode AVIF is narrower than the cohort that decodes WebP. Save it for <picture> tags in the article body; do not point og:image at it.
PNG for hard-edged content, JPG for photographic content, both under 300 KB, both at1200×630. WebP and AVIF stay in the article body, never inog:image. Run a real iMessage send before you announce.
This is one of those rare web-platform decisions where the simple answer is also the correct one. The optimization frontier moved years ago; the compatibility frontier did not. Pick the older format every time and the cards just work.
Our free OG Image Generator outputs a clean PNG at 1200×630, sRGB, optimized to under 100 KB on most templates. No signup, no watermark, no upload to a third-party server — everything renders in your browser and downloads directly to your machine.
Yes — X's preview service has decoded WebP since 2023. The reason to avoid WebP for og:image in 2026 is not X but iMessage, Outlook desktop, and the self-hosted RSS reader long tail. If X is your only meaningful sharing channel, WebP is fine; for most sites it is not.
WebP versus PNG versus JPG is not a ranking signal. Page load time is, and a 70 KB WebP loads measurably faster than a 200 KB PNG on the page itself. That is exactly why WebP belongs in <img> tags on your article. The OG image is fetched once by a scraper, not by every reader, so its payload is a rounding error on page performance.
You can detect facebookexternalhit or Slackbot and serve a JPG to them while serving WebP to humans. It works. It also creates a debugging nightmare the first time something breaks and you cannot tell whether a card is broken or you are looking at the wrong format. For 99% of sites, ship one PNG or one JPG everywhere and move on.
Hard ceilings sit around 5 MB on iMessage and X, 8 MB on Discord, and 10 MB on Slack. The realistic target is under 300 KB — far below any of those ceilings — because Google Discover silently drops cards over 1 MB from its carousel. We covered the full ceiling table in our companion piece on OG image dimensions in 2026.