Dynamic OG Image API vs Self-Hosted: Which to Use

A dynamic OG image API is an HTTP endpoint that turns a page's title (or its URL) into a branded 1200×630 social card on demand — you point your og:image tag at it instead of designing a card by hand for every post. You have two ways to get one: rent a hosted API that runs the rendering for you, or self-host an open-source renderer like @vercel/og. This post compares the two on the axes that actually decide the choice — cost, control, speed, and maintenance — so you can pick without rebuilding later.

What does a dynamic OG image API actually do?

It renders a unique Open Graph image per page at request time. You design one template — logo, brand color, typography — and the API fills in the variable text (title, author, date) from query parameters or the scraped page. The output is a standard PNG served at an absolute HTTPS URL, which you set as your og:image meta tag. The platform that scrapes your link reads that tag, fetches the image, and shows it in the preview.

The payoff is leverage. A link preview with an image earns far more engagement than a bare URL, and doing it manually for hundreds of posts is the work nobody finishes.

Hosted API vs self-hosted: how do they compare?

Both produce the same artifact — a per-page PNG. The difference is who runs the renderer, who tunes the cache, and who fixes it at 2am.

The honest summary: a hosted API trades a little flexibility for zero infrastructure, and self-hosting trades engineering time for total control and no marginal cost. Neither is "better" in the abstract — it depends on whether template control or shipped-today matters more to you.

When is self-hosting @vercel/og the right call?

Self-host when you have engineering time, want pixel-level template control, and expect enough volume that per-render fees would add up. @vercel/og uses Satori to convert a React component plus a CSS subset into an SVG, then rasterizes it to PNG at the edge — fast and genuinely flexible.

The hidden costs are real, though. You ship and debug font files (web fonts don't "just work" in Satori — you load the buffer yourself), handle emoji, and design the cache so the same URL isn't re-rendered on every scrape. That last one bites people: an uncached endpoint re-rasterizes on every Facebook, X, and Slack fetch of the same link.

If you want to go this route, the 2026 social media image size cheat sheet has the exact dimensions and file-size ceilings every renderer has to respect.

When is a hosted API the better choice?

Choose a hosted API when you want branded cards live today, don't want to own rendering infrastructure, and would rather spend your time writing than tuning a cache. For most Ghost and WordPress bloggers, that's the whole list.

The branding payoff compounds. Consistent brand color across every card isn't decoration — it's recognition.

This is exactly the gap Social Card Studio fills: it derives your logo, colors, and site name from your blog, then auto-generates a branded 1200×630 card for every post — no template code, no font files, no cache to babysit. You can see the output instantly with the free Open Graph image generator.

Does the rendering approach affect AI search visibility?

Indirectly, yes — and it's worth knowing. AI answer engines and social scrapers both read your og:image tag, so a reliable dynamic endpoint means every shared and cited link carries a real card instead of a blank box. The renderer doesn't change what's in the image, but it changes whether the image is there consistently.

The practical rule: pick whichever approach you'll actually keep working. A self-hosted route that breaks when a font CDN changes is worse than a hosted card that just renders. If a preview ever does come back blank, work through why your link preview is broken before blaming the renderer.

The one-line takeaway

A dynamic OG image API gets every page a branded social card from a single meta tag. Self-host @vercel/og if you want total template control and have the engineering time; use a hosted API if you'd rather have correct, branded cards shipping today. Either way, target 1200×630 under 200 KB at an absolute HTTPS URL — that's the card that works everywhere.