OG image file formats

The format you put in og:image is separate from what your CDN serves to browsers. Many sites deliver WebP to Chrome while still needing a PNG or JPG for Facebook, LinkedIn, WhatsApp, and X. This guide covers format choice, compression, and verification.

Recommended defaults

Format	Best for	Notes
PNG	UI cards, logos on flat color, sharp type	Larger than JPG for photos; compress carefully
JPG	Photographs, soft gradients	Great byte efficiency; watch banding on flat UI
WebP	On-page images for modern browsers	Risky as the only og:image—crawler support varies
SVG	Site icons/illustrations	Not for og:image—rasterize first
GIF	Rare	Prefer a static frame

Safe pixel size remains ~1200×630 (OG image size). Design habits: best practices.

Why WebP is a special case

Your theme may auto-convert uploads to WebP for performance. That helps page speed and can hurt previews if the meta tag points at a WebP-only URL some crawlers mishandle. Practical approach:

1. Keep a PNG/JPG master for social.
2. Point og:image at that master.
3. Let the page <img> tags use WebP/responsive sources separately.

Compression without wrecking type

• For PNG UI cards: reduce palette or use a generator that exports lean PNGs (OG Image Generator).
• For photos: export JPG at a quality that stays sharp at 1200px wide; avoid tiny highly compressed messes.
• Use the Image Resizer when you need an explicit byte target.
• Validate with the Social Image Checker.

WhatsApp is the strictest common consumer on weight—see WhatsApp link preview not working and the comparison guide when Facebook already passes.

Content-Type and URLs

The URL in og:image should return an image Content-Type (for example image/png or image/jpeg) to anonymous GET—not an HTML error page. Check:

1. Private window fetch
2. Link Preview Checker
3. No auth redirects

CMS “dynamic image” endpoints that HTML-wrap the file will fail.

Animated and multi-frame assets

Do not expect Discord, Slack, or WhatsApp to play animated OG images consistently. Export a representative still. Put motion in the page body instead.

Migration checklist (WebP sites)

1. Inventory URLs currently in og:image.
2. Replace WebP-only social URLs with PNG/JPG equivalents.
3. Deploy HTML changes.
4. Re-scrape Facebook/LinkedIn; use URL variants for WhatsApp/X/Slack/Discord caches.
5. Confirm View Source still points at raster files after the next CMS sync.

Common mistakes

• Tagging /uploads/hero.webp because “the site uses WebP everywhere”
• Uploading a 5 MB PNG with negligible visual gain
• Using SVG logos as og:image
• Hotlink protection that serves HTML challenges to bots

Checklist

• og:image is PNG or JPG
• ~1200×630; bytes appropriate for your networks
• Absolute https; correct Content-Type
• WebP reserved for on-page display if desired
• Checker confirms before major campaigns

Still missing images after format fixes? og:image not showing.

Pipeline recommendations

Authors should export social masters as PNG or JPG from the design tool, not as the WebP derivative your image CDN prefers for on-page <img> tags. Store masters in a /og folder with stable names. Let the on-page responsive image pipeline convert separately.

If your CMS rewrites all uploads to WebP automatically, add an exception for paths used in Open Graph, or maintain a parallel non-WebP copy. Automated audits that flag “OG points at WebP” save hours of platform-specific debugging.

Retesting after a format change is mandatory: some caches key on URL only, so switching from .webp to .png at a new path is safer than content negotiation on the same URL. Update HTML, deploy, then re-scrape or version the share URL.

Field notes from real share failures

Most broken previews are boring: a relative URL, a duplicate plugin tag, a cache that nobody re-scraped, or a file that is fine in Chrome but too heavy for a messenger. Resist the urge to rewrite the entire brand system until those basics are proven in View Source and a private window.

Write down the exact URL string you tested, including trailing slash and query parameters. Support threads go sideways when one person scrapes example.com/page and another shares example.com/page/. Treat the share string as part of the specification.

When you finally change artwork, change the path. Overwriting og.png in place is the most common reason a “fixed” card never appears. Pair the new file with a short note in your changelog so the next person knows which version is live.

Verification habits worth repeating

After every deploy that touches templates or SEO plugins, spot-check three URLs: the homepage, one article or product, and one utility page. Look for a single absolute og:image and open that file logged out. This ten-minute habit catches more regressions than redesigning share cards.

Document the owner of social tags for your stack—theme, plugin, or layout component—in the repository README. When something breaks, people should know which lever to pull first. Ambiguous ownership is how duplicate tags accumulate.

Finally, separate “works in our browser” from “works for crawlers.” If you only validate inside an authenticated preview session, you will ship failures to Facebook, LinkedIn, Slack, Discord, WhatsApp, and X without noticing until a campaign is live.

If you only remember one rule, remember this: crawlers are blunt. They fetch a URL, read tags, fetch an image, and cache aggressively. Your CMS preview, authenticated browser session, and hydrated React tree are not part of that path. Design the HTML and the image file for the crawler first, and human polish second. That ordering keeps share cards reliable while you iterate on the visible page design.