OG Image Generator

The choice between dynamic and static OG images comes down to volume and variation, not technical sophistication. Dynamic OG generation \u2014 using a service like Vercel's @vercel/og or Cloudflare Workers \u2014 generates a unique image per URL at request time, pulling in the page title, author, and any other variable content. It's powerful for blogs with hundreds of posts, documentation sites with many pages, and any product where every URL needs its own preview.

Static OG images, in contrast, are pre-designed in a tool and uploaded as files. You commit them to your site or upload them to a CDN, then reference them in your og:image meta tag. They're the right choice for marketing pages, landing pages, product pages, and any URL where the preview won't change often. They're also more visually flexible because you're designing in a real editor, not constrained by what code can render.

The hybrid approach most growing teams land on: static OG images for the home page, pricing, and a handful of marquee marketing pages \u2014 designed with care and refreshed quarterly. Dynamic OG images for blog posts, changelog entries, user-generated pages, and anything that scales beyond what a designer can manually produce. This combination gives you the best of both: polish where it matters most and scale where it's required.

One frequently missed nuance: dynamic OG images cost compute on every share. If your post goes viral and thousands of services request the OG image simultaneously, you need caching at the CDN layer to avoid generating the same image hundreds of times. Static images don't have this problem \u2014 they're just files served by your CDN. For high-traffic pages, the simpler architecture often wins.

Slack and Discord both render OG images in chat unfurls, but they crop differently. Slack honors the OG image at roughly 1.91:1 (matching the 1200\u00d7630 standard) but compresses heavily for inline display, sometimes losing fine text detail. Discord renders the preview at a smaller size on desktop and may skip the image entirely on mobile depending on user settings. Both platforms cache aggressively \u2014 once an OG image is fetched for a URL, the cached version may stick around for hours or days, which is the most common reason updates "don't work."

LinkedIn is the strictest about image dimensions. Anything that deviates significantly from 1.91:1 gets letterboxed or cropped, and LinkedIn's post inspector tool is the only reliable way to confirm the rendering before publishing. LinkedIn also caches OG images at the URL level \u2014 if you update the image but the URL stays the same, you have to manually clear the cache through the post inspector, which is hidden in the developer tools.

Twitter renders OG images at the largest size in the timeline (the "summary_large_image" card), but only if you've set the twitter:card meta tag explicitly. Without it, Twitter falls back to the smaller summary card which most teams don't want. Twitter also re-crawls aggressively when you share a link, but the displayed image still comes from its cache \u2014 if you update the OG image and re-share within a few minutes, you may see the old version.

The practical workflow: design at 1200\u00d7630, test in each platform's preview tool before publishing (LinkedIn Post Inspector, Twitter Card Validator, Facebook Sharing Debugger), and assume aggressive caching everywhere. When you update an OG image, expect a 24-hour delay before everyone sees the new version unless you explicitly bust the cache. If you're building OG images alongside social media mockups and Twitter cards, keep them visually consistent so a shared link feels like part of the same brand across every platform.