OG Image Generator: How to Automate Social Preview Images

An OG image generator is a tool that produces the image a browser, Slack, or a social feed shows when someone shares your link — the og:image tag's actual contents, generated automatically instead of exported by hand in a design tool. If you've ever opened Figma, made a 1200×630px card, exported a PNG, and uploaded it to your CMS for a single blog post, you've done manually what a generator does on every publish, for every page, without you touching a design file again.

Why manual export stops working

For a five-page marketing site, manual export is fine. You make five images once and move on. The problem shows up at the second stage of almost every site's life: a blog that publishes weekly, a product catalog that adds SKUs, a marketplace where users create their own listings. At that point the image isn't a design task anymore, it's a process — someone has to remember to make one every time content ships, and someone has to notice when they forget. Most teams don't catch the miss until a page has been live for a month sharing a generic fallback image, or worse, no image at all.

The failure mode is quiet, which is what makes it expensive. A missing or wrong og:image doesn't break your site. It doesn't throw an error. It just means every link shared from that page underperforms — lower click-through in a Slack channel, a blank gray box in a Twitter feed, a stock placeholder next to a real product listing. Nobody files a bug for it because nobody sees it unless they specifically go looking, and by the time someone does, dozens or hundreds of shares have already happened with the broken version.

What an og image generator actually does

At the core, a generator takes a template — a fixed layout with placeholders for text, an image, and brand colors — and a set of variables for a specific page, and renders a finished image at request time or publish time. You design the layout once: where the headline sits, how large the logo is, what the background treatment looks like. Every page that uses that template inherits the layout, and only the variables change: this page's title, this product's photo, this post's category label.

• A fixed template defines layout, fonts, and safe margins once
• Per-page variables (title, description, hero image, category, price) fill the template at render time
• Output is a real image file at a URL, served the same way a static asset would be
• New content automatically gets a correctly sized, on-brand preview with zero manual export

Build vs. buy

Some teams build this themselves — a script that takes a headless browser or a rendering library, feeds it an HTML template, and screenshots the result into a PNG. It works, and for a single well-understood use case it can be the right call. The costs show up later: someone has to maintain the rendering pipeline, handle font loading and fallback behavior, manage caching so you're not re-rendering the same image on every request, and rebuild the whole thing if the rendering library gets deprecated or the hosting platform changes how it handles headless browser processes. None of that is hard exactly, but all of it is time spent on infrastructure instead of on the actual page content.

Buying a generator trades that maintenance burden for a monthly cost, and the calculation usually comes down to how much of your team's time the DIY version would actually consume, honestly counted — not just the initial build, but every time a font renders wrong on a new content type, or a template needs updating for a rebrand, or someone asks why last month's rendered images look different from this month's after a dependency update nobody tracked.

What to look for in a tool

Not every generator is built the same way, and the differences matter more once you're relying on it for hundreds of pages rather than five. A few things worth checking before you commit to one:

• Versioned, immutable render URLs — publishing a template change shouldn't retroactively alter images already shared and cached by Facebook or Slack
• Variable support for text, images, and color, not just text substitution into a fixed background
• Fast render times — a slow generator delays the crawler fetch, and some crawlers give up and fall back to no image at all
• A way to preview the actual rendered output before it goes live, not just the template editor's approximation
• Reasonable output at 1200×630px with correct format and file size, without you having to configure image compression by hand

That versioning point is worth dwelling on, because it's easy to overlook until it bites you. If you edit a template and the underlying image URL for old posts changes too, every previously shared link now points at different content than what the crawler cached — which can look like the image silently broke, even though nothing actually failed. A generator that treats each published version as immutable avoids that entirely: publishing creates a new version at a new URL, and anything already shared keeps working exactly as it did the day it was shared.

Rollout: retrofitting an existing site versus starting fresh

Setting up an og image generator on a brand-new site is the easy case — you design the template alongside the pages themselves, and every page launches with a correct preview from day one. The harder, more common case is retrofitting a generator onto a site that's already live with hundreds of pages and years of accumulated inconsistency: some pages have a hand-exported image from three redesigns ago, some have nothing at all, and a few have an image that technically loads but no longer matches the page's actual content. Bolting a generator onto that isn't a single afternoon of work, and treating it like one is how retrofits stall out halfway through.

The more reliable approach is to treat it as a staged migration rather than a flip of a switch. Start by auditing what's currently live — which pages have a working og:image, which are missing one, which have one that's stale or mismatched — so you know the actual size of the gap rather than guessing at it. Then build the template against your highest-traffic or highest-value page type first (usually blog posts or product pages, whichever drives more shares), verify it holds up against real content, and only then expand the rollout to the rest of the site. Trying to cover every content type in the first pass usually means the template gets designed against whichever page type happens to be top of mind, and it shows the moment a different content type runs through it.

Signs it's time to move past manual export

It's worth being honest about when a generator is actually necessary versus when it's solving a problem you don't have yet. A handful of clear signals are worth watching for: content publishing has moved from occasional to routine, meaning someone would need to remember to export an image on every single publish; more than one person publishes content, meaning the person setting up the image and the person publishing it aren't always the same, which is exactly the gap where steps get skipped; or you've already found a page live with a missing, wrong, or stale preview and had to fix it reactively. Any one of these on its own is a reasonable prompt to stop treating OG images as a manual design task.

How useopengraph handles this

useopengraph is built around exactly this template-plus-variables model. You design a template once — text, image, and color variables — and every page that uses it renders through a versioned URL in the shape /api/render/{templateId}/v{version}/..., where publishing a change to the template creates a new version rather than mutating the old one. That means a post you shared six months ago keeps rendering the exact image that was live when it was shared, while new content automatically picks up the current template. For teams that outgrew manual export a while ago, that's the actual shift: OG images stop being a task on a publish checklist and become a property of the template that new content simply inherits.