OG image best practices

Open Graph images are tiny billboards. They fail when type is unreadable, files are enormous, URLs are fragile, or caches stick to old binaries. This reference collects design and hosting habits—not platform debugger walkthroughs (those live in troubleshooting guides) and not raw pixel tables (see OG image size and per-network size pages).

Start with a consistent canvas

Use 1200×630 as your master. Export from the OG Image Generator or templates at OG image templates. Check real-world crops against OG image examples.

Safe zone

Imagine a frame inset ~10% from each edge. Keep headlines, CTAs, and logos inside that zone. Background color or imagery can bleed; text should not.

Contrast and type

• Prefer high contrast between type and background.
• Limit headlines to a few short words—WhatsApp and mobile embeds shrink everything.
• Avoid hairline fonts and busy full-bleed photography behind small type.

Brand without clutter

One logo mark, one headline, optional subtitle. Badges, stickers, and dense UI screenshots become mud at embed size.

File weight and formats

Heavy files break WhatsApp and slow other crawlers. Aim for a lean PNG or a moderate JPG. Details: OG image file formats and WhatsApp troubleshooting.

Use the Image Resizer and Social Image Checker before you publish.

Hosting habits

1. Absolute https URLs in og:image.
2. Stable public objects—no expiring signatures for the tagged URL.
3. Versioned filenames when art changes (launch-v2.png).
4. One tag source in the HTML—CMS plugins fighting each other create chaos (og:image not showing).
5. Fast responses—static files beat cold dynamic renderers for the tagged URL.

Width, height, and alt

<meta property="og:image" content="https://example.com/og/launch-v2.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Launch notes: new dashboard preview" />

og:image:width and og:image:height help some clients pick a large card on first fetch. og:image:alt should briefly describe the image for accessibility—similar spirit to HTML alt, not a keyword list. Build tags with the Meta Tag Generator or the OG tags cheat sheet.

Workflow that scales

Stage	Action
Design	1200×630, safe zone, contrast
Export	PNG/JPG, check bytes
Publish	Absolute URL in server HTML
Verify	Link Preview Checker
Update	New filename + platform re-scrape

Framework notes: Next.js, Astro, WordPress, Shopify, Webflow.

Common anti-patterns

• Screenshots of entire webpages with unreadably small UI
• Pure text walls that wrap into five lines on mobile unfurls
• Transparent PNGs that disappear on dark Discord themes without a background
• Reusing the same og.png forever while changing pixels in place

Checklist

• 1200×630 with safe margins
• Strong contrast; short headline
• Lean PNG/JPG; absolute https
• Optional width/height/alt set honestly
• Versioned path after visual changes
• Checker green before major shares

Team checklist for campaigns

Before a launch email or paid push, require a screenshot of View Source showing og:image, a private-window load of the image file, and a Link Preview Checker result. Designers attach the 1200×630 master to the ticket; engineers confirm the deployed URL. That three-person handshake prevents most “why is the old logo still showing” emergencies.

Localization and seasonal variants should use distinct filenames (summer-sale-2026.png) rather than overwriting og.png. Caches on Facebook, LinkedIn, Slack, Discord, and WhatsApp all behave more kindly when the path changes. Keep a simple registry of which campaign uses which asset.

Accessibility is part of quality: og:image:alt should read like a human description. “Blue chart with Q3 revenue up 12 percent” is better than “image1”. You do not need keyword lists in alt text. Pair alt with on-image type that remains legible when color is desaturated.

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. Ship the checklist with every release that touches head tags or media pipelines.