February 7, 2026

Dynamic OG Images: How to Auto-Generate Social Cards for Every Page

Manually creating OG images doesn't scale. Here's how to auto-generate social cards for blogs, e-commerce products, and SaaS pages — and when to use each approach.

By Sharon Onyinye

Dynamic OG Images: How to Auto-Generate Social Cards for Every Page

You published 50 blog posts. Each one needs a unique OG image. You have two choices: spend hours in Figma, or automate the whole thing.

If you're running a blog, a SaaS product with dozens of feature pages, or an e-commerce store with thousands of products, manual OG image creation stops being viable fast. Dynamic OG images solve this.

Why Dynamic OG Images Matter

Every shared link is a chance to earn a click. But that only works if the preview image is relevant, readable, and on-brand.

Here's the problem with static OG images at scale:

Blogs need a unique image per post. 100 posts means 100 images.
E-commerce needs product-specific cards. Nobody clicks a generic store logo.
SaaS products have landing pages, docs, changelog entries — each deserving its own preview.

When you skip unique OG images, platforms either show a generic fallback or grab a random image from your page. Neither looks intentional. Neither gets clicks.

Dynamic generation means every page gets a polished, branded social card — automatically.

The Three Approaches to Dynamic OG Images

There are three ways to tackle this, and each fits different situations. Understanding the trade-offs saves you from picking the wrong one.

1. Template-Based with a Visual Tool

This is the fastest path for most teams. You design a template once — choosing your background, layout, font, and brand elements — then swap in page-specific content (title, description, screenshot) for each new page.

With Screenhance's OG image generator, the workflow is straightforward:

Upload a screenshot of the page or product
Pick a device frame and background that matches your brand
Add your headline text
Export at the correct OG dimensions (1200 x 630)

You get a unique, polished image in under two minutes. No design skills needed.

Best for: Teams that publish weekly or monthly. Blogs with 10-100 posts. Landing pages and feature pages where each image should feel crafted. Pros: High visual quality, full creative control, no engineering time. Cons: Still requires a human in the loop for each image.

2. Fully Programmatic (Vercel OG, Satori, Puppeteer)

This approach generates images at build time or on request using code. You write a template in JSX or HTML, feed it dynamic data, and the system renders an image.

Vercel OG / Satori is the most popular option right now. It converts JSX to SVG, then to PNG. It runs on the Edge, so it's fast. You define your layout in React-like syntax:

Set background colors, gradients, or images
Position text dynamically based on title length
Include logos, author avatars, or category badges
Output at standard OG dimensions

Puppeteer / Playwright takes a different approach — it spins up a headless browser, renders an HTML page, and takes a screenshot. More flexible but slower and heavier. Best for: Engineering teams that need zero-touch image generation for hundreds or thousands of pages. Content-heavy sites where no human should be involved in image creation. Pros: Fully automated, scales infinitely, consistent output. Cons: Requires engineering setup and maintenance. Limited design flexibility compared to visual tools. Debugging layout issues in code is painful.

3. Hybrid Approach

The smart move for many teams is combining both. Use a visual tool for high-value pages (homepage, top landing pages, key product pages) and programmatic generation for everything else (blog posts, docs, changelog).

Your homepage OG image deserves 15 minutes of attention. Your 200th changelog entry does not.

The hybrid workflow:

Design a branded template using a social card generator
Export it as your design reference
Implement a code-based generator that approximates that template for bulk pages
Manually create images for your top 10-20 pages

This gives you the best of both worlds: polished images where they matter most, and automated coverage everywhere else.

When Each Approach Makes Sense

Choose template-based if:

You publish fewer than 10 pages per month
Visual quality is more important than speed
Your team includes a marketer or designer who can spend 5 minutes per image
You want each OG image to feel unique and intentional

Choose programmatic if:

You have thousands of pages (product catalog, documentation, user profiles)
New pages are created automatically (user-generated content, dynamic routes)
Engineering time is cheaper than design time for your team
Consistency matters more than uniqueness

Choose hybrid if:

You have a mix of high-value and bulk content
You want the best results without over-investing in either approach
Your homepage and landing pages need to look amazing, but your blog just needs to look good

Getting the Most from Dynamic OG Images

Regardless of which approach you choose, these principles apply:

Keep Text Short and Large

Your title will be read at thumbnail size. Five to seven words maximum. If the text doesn't read clearly at 300px wide, it's too long or too small.

Use High-Contrast Backgrounds

Over 80% of Twitter users are on dark mode. Your OG image will sit against a dark background most of the time. Light pastel backgrounds with light text disappear. Bold colors and strong contrast survive every context.

Include a Visual Element

Text-only OG images work, but images with a product screenshot, illustration, or visual element get higher engagement. Even a simple icon next to your headline adds visual interest.

Brand Consistently

Whether you generate images manually or programmatically, maintain the same color palette, font choices, and layout structure. When someone sees your OG image in a feed, they should recognize your brand before reading the text.

Test Before You Ship

Twitter Card Validator, LinkedIn Post Inspector, and Facebook Sharing Debugger let you preview how your OG image will render. Test every template change before deploying. Platforms cache aggressively — a broken OG image can haunt you for days.

Common Mistakes to Avoid

Forgetting mobile rendering. Most social media consumption happens on phones. Your OG image will be smaller than you think. Design for that. Using the same image for every page. This defeats the purpose entirely. If every shared link looks identical, people stop paying attention. Ignoring platform differences. Twitter crops differently than LinkedIn. Facebook has different minimum sizes. A one-size-fits-all image can work (1200 x 630 is the safe bet), but test across platforms. Not setting a fallback. If your dynamic generation fails, you need a default image that still looks good. Never let a platform render a blank card.

The Bottom Line

For most teams, starting with a template-based approach using a visual tool is the fastest path to better OG images. You can always add programmatic generation later when your content volume demands it.

The teams that get the most clicks from social shares are the ones that treat OG images as a first-class part of their content pipeline — not an afterthought bolted on at the end.

Start with your highest-traffic pages. Make those OG images great. Then scale from there.

Build vs Buy: When a Third-Party OG Service Is the Right Call

There is a quiet decision buried in "dynamic OG images" that most engineering teams skip past: whether to run the generation yourself or hand it to a service. The reflex answer is usually "we will build it" because Vercel OG ships in a few hours and the demo looks great. The reflex is often wrong.

Vercel OG, Cloudflare's image workers, and similar at-edge generators are real engineering surface area, not free utilities. You own the template code. You own the font loading, the fallback fonts when a glyph is missing, the cold-start performance on edge runtimes, the cache invalidation when someone publishes a typo'd title, and the gnarly debugging when a particular blog post breaks layout because the headline was unusually long. None of these are hard problems individually. Together, they are a few engineer-weeks of attention every year that you did not budget for.

A third-party OG service makes sense when your differentiation is not "having unique OG images" but "shipping the underlying content." If you are a blog, a documentation site, a startup landing page, or anything where the OG image is a derivative of the actual product, paying for generation is almost always cheaper than maintaining your own pipeline. The decision flips the other way when the OG image is the product — a generative art tool, a meme generator, an actual social-graphics SaaS. Those teams need full control over the rendering stack.

The middle ground that works well for most teams is using a tool like Screenhance's OG image generator for the bulk of pages and reserving custom code only for templates that genuinely need bespoke rendering (charts that pull live data, dashboards that reflect user state, anything where the visual changes more often than your design system does). Pay for the easy 80% and build the hard 20%, not the other way around.

OG Image Caching, CDN, and the Stale-Image Trap

The most common bug in dynamic OG implementations has nothing to do with the rendering pipeline. It is caching, and it bites every single team eventually.

The trap looks like this. You ship a new post. You share it on Twitter. The OG image is wrong — old title, old gradient, missing screenshot. You check your generator: looks correct in a fresh browser tab. You check your meta tags: correct URL, correct dimensions. You scratch your head for an hour before realizing Twitter cached the OG image when their crawler hit your page two weeks ago for a different post that happened to live at the same URL. The image is right, the cache is wrong, and there is no flush button you control.

Two practical defenses. First, version your OG image URLs. Append a content hash or a `?v=2026-05` parameter so that any real change in the underlying content produces a different URL. Platforms cache by URL; new URL means new fetch. Second, use the platform debugger tools (Twitter Card Validator, LinkedIn Post Inspector, Facebook Sharing Debugger) to manually re-scrape critical pages after a redesign or template change. They are slow and clunky but they are the only way to forcibly invalidate the social platforms' caches.

The CDN layer adds another wrinkle. If you cache your OG image responses at the CDN with a long TTL, the platform crawler will get the cached version even if your origin has the new one. Set short cache headers on the OG endpoint itself (a few minutes is enough) and rely on URL versioning to handle longer-lived cache scenarios. The pattern most teams converge on: short edge TTL, content-hashed URLs, and an automated re-scrape ping to the major platforms whenever a high-value page is updated.

Frequently Asked Questions

How expensive is at-edge OG image generation in practice?

For a typical content site, the rendering cost is negligible — Vercel OG runs in milliseconds and even with thousands of pages, generation happens on demand rather than for every page at once. The real cost is not compute but cache traffic. Every time a social platform's crawler fetches your OG image, it counts against your bandwidth budget, and platforms re-crawl unpredictably. Sites with viral content can see surprising bandwidth bills from OG images alone if every share triggers fresh fetches. Cache aggressively at the edge and the actual dollar cost stays trivial.

Vercel OG or Cloudflare Workers — which is better for OG generation?

If your site is already on Vercel, Vercel OG is the path of least resistance — same deployment pipeline, same observability, same auth. If you are on Cloudflare, their image transformation API combined with Workers is competitive on cost and arguably better at the CDN layer because the rendering happens at the same edge as the rest of your traffic. The honest answer is that for OG generation specifically, both are good enough and the difference is a few hundred dollars a year for most sites. Pick the one that lives closest to the rest of your stack.

How do I version OG images so social platforms re-fetch after a redesign?

The cleanest pattern is to embed a content hash or version string in the OG image URL itself — for example, `/og/blog/my-post.png?v=2026-05-17` or `/og/blog/my-post-a7c4f.png`. Social platforms cache by URL, so any change to the URL forces a new fetch. Couple this with updating your meta tag whenever the underlying content changes, and you avoid the stale-cache trap entirely. For site-wide redesigns, bumping a global version parameter across all OG URLs is the fastest way to refresh everything without contacting individual platform debuggers.

What is the best way to debug an OG image that is not rendering correctly?

Start with the platform's own debugger — Twitter Card Validator, LinkedIn Post Inspector, Facebook Sharing Debugger. They show exactly what the platform sees when it crawls your URL, including the raw OG metadata it parsed and the image it fetched. Most "broken OG image" reports turn out to be one of three things: a wrong absolute URL in the meta tag, an image that the crawler is being rate-limited or blocked from fetching, or a cached version of the page from before you fixed the issue. The debuggers diagnose all three.

Should I always have a static fallback image alongside dynamic generation?

Yes, and the failure mode you are guarding against is not "the generator broke." It is "the platform crawler hit your endpoint during a deploy or a cold start and got a 500." The fallback should be a hand-crafted site-wide OG image set as the default `og:image` meta tag, with the dynamic image overriding it on a per-page basis. If the dynamic image fails to render or fetch, the platform falls back to your default. That single line of defensive design is the difference between a temporary blip and a week of social shares with a blank preview card.

Ready to create stunning mockups?

Try Screenhance free - no credit card required.

Start Creating Free