Static vs Dynamic OG Images: Which Approach Actually Fits Your Site?
Once you've decided every post deserves its own social image instead of one shared default, there's a second decision that actually matters more for a real setup: generate every image once, ahead of time, or generate each one on demand when a crawler requests it. Both are common, well-established approaches, and they solve the exact same visible problem in very different ways.
The static approach: generate once, host the files
A batch tool (or a build-time script) produces a PNG for every post in one pass, and those files get uploaded and referenced directly by each page's og:image tag — plain image files, served exactly like any other image on the site. There's no server-side logic involved at request time at all; a crawler fetching the image gets a static file from a CDN or file host, the same as it would for a hand-designed graphic.
The dynamic approach: generate per request
A serverless function (Vercel's @vercel/og and similar tools on other platforms are the common implementations) builds the image on the fly, reading the page's title and other metadata from the URL itself and rendering a fresh image for that specific request. Nothing is pre-generated or stored ahead of time — the image is computed the moment something requests it, then often cached at the edge afterward.
Where static wins
Zero runtime dependency: a static site with no server (GitHub Pages, a plain CDN, any purely static host) can use pre-generated images without adding any server-side capability at all, which matters a lot for sites that are static by design. It's also simpler to reason about and debug — the image that exists is the image that gets served, with no request-time logic that can fail, time out, or produce unexpected output under edge-case input.
Where dynamic wins
Content that changes after publication — a live view count on the card, a price that updates, a title that gets edited post-publish — stays accurate automatically with a dynamic approach, since the image reflects live data on every fetch rather than a snapshot from whenever it was generated. It also removes the batch-regeneration step entirely: add a new page, and its image exists the first time anything requests it, with nothing to remember to re-run.
Which one actually fits most sites
For a blog, documentation site, or any content that's essentially fixed once published — which describes most sites — static wins on simplicity without giving up much: regenerating a batch after a title edit takes the same one pass it took the first time, and there's no serverless function to maintain, monitor, or pay for as traffic scales. Dynamic generation earns its added complexity specifically when card content needs to reflect something that changes independently of a content edit — live data, not just the title.
Generate a static batch
FreeToolDev's bulk OG image generator takes the static-batch approach — paste a list of titles, get a unique image for every one, host the files anywhere. No server required, which fits a purely static site (like this one) by design. See this post for why a unique image per post is worth doing in the first place.