The short version
- A dynamic OG image is an Open Graph preview image generated automatically for each page, usually from its title, category and a consistent brand background.
- The standard size is 1200 × 630 pixels, and the page must point to the image with an absolute URL in its og:image tag.
- You can generate OG images once at build time, which is cheapest, or on request, which suits pages whose data changes, as long as the result is cached.
- Platforms cache preview images per URL, so changing an image usually means changing its address or asking the platform to fetch the page again.
- Design the template for a thumbnail: a short title in large type, generous margins and a background that stays recognisable when small.
On this page
A dynamic OG image is a link preview image that your site generates for each page, instead of someone designing it by hand. When a page is shared on LinkedIn, in Slack or in a chat app, the platform fetches the image named in the page's og:image tag. If that image is built from the page's own title and data, every article, product and profile gets a preview that says exactly what it is.
This guide covers the template design, the two ways to generate images, the tags that connect them, caching and testing. For the size itself and how platforms crop, see our guide to the Open Graph image size.
Why every page should have its own OG image
The preview is often the first thing someone sees of your page, and in a busy feed it is most of what they see. One generic logo card for the whole site makes every shared link look the same, so none of them says what is behind it. A per-page image carries the page's actual title in your visual identity: recognisably yours, and specific enough to earn the click.
One template, filled with one article's title…
…and another's. Consistent enough to recognise, specific enough to click.
Designing an OG image template
Design the template the way you would design a thumbnail, because that is how it is usually seen. Previews appear at a fraction of their real size, and some apps show a smaller cropped version. The words that matter should survive both.
- 1
Start at 1200 × 630
Design at full size, then check it at a quarter of that. If you can't read the title at 300 pixels wide, it is too small or too long.
- 2
Use the title, not the whole page
One line of large type, or two at most. Long titles need a rule: shorten them in data, or step the font size down once they pass a set length.
- 3
Keep margins wide
Keep the title and logo away from the edges so a tighter crop doesn't cut them. Around 60 to 80 pixels of margin at this size is a sensible starting point.
- 4
Add one piece of context
A small label for the section, author or date helps people place the link. More than one extra line turns a preview into a document.
- 5
Make the background carry the brand
A consistent gradient or material does more for recognition than a large logo. Keep its brightest, busiest part away from the words; text on a gradient explains how.
Weak preview
- The same logo card on every page
- Full title and description squeezed in small type
- Text touching the edges
- A busy photo behind white words
Strong preview
- The page's own title, large
- One short label for context
- Wide margins that survive a crop
- A calm brand background with clear contrast
Generating OG images at build time or on request
There are two moments to make the image. At build time, your site renders an image for every page once and serves it as a static file: fast, cheap and ideal for articles and docs. On request, a route draws the image the first time it is asked for: right for pages whose data changes, such as a profile's follower count or a product's price. On-request images must be cached, or every share and every crawler visit repeats the work.
| Approach | Best for | Watch out for |
|---|---|---|
| Build time | Articles, docs, landing pages | Build time grows with the number of pages |
| On request, cached | Profiles, products, user content | Set cache headers; cold renders are slower |
| Hand-made | A handful of key pages | Doesn't scale, and drifts out of date |
Most frameworks have a way to draw an image from HTML-like markup. In Next.js, an opengraph-image.tsx file beside a route generates that route's image with ImageResponse, and Next adds the meta tags for you. The same idea works elsewhere with a headless browser taking a screenshot of a template page.
// app/guide/[slug]/opengraph-image.tsx
import { readFile } from 'node:fs/promises'
import { join } from 'node:path'
import { ImageResponse } from 'next/og'
import { getArticle } from '@/lib/articles'
export const size = { width: 1200, height: 630 }
export const contentType = 'image/png'
export default async function Image({ params }: { params: Promise<{ slug: string }> }) {
const { slug } = await params
const article = await getArticle(slug)
const font = await readFile(join(process.cwd(), 'assets/Inter-SemiBold.ttf'))
return new ImageResponse(
(
<div
style={{
width: '100%',
height: '100%',
display: 'flex',
flexDirection: 'column',
justifyContent: 'flex-end',
padding: 72,
backgroundImage: 'linear-gradient(135deg, #120a2e 0%, #4c1d95 55%, #db2777 100%)',
color: '#ffffff',
fontFamily: 'Inter',
}}
>
<div style={{ fontSize: 28, opacity: 0.8 }}>Field Guide</div>
<div style={{ fontSize: article.title.length > 40 ? 60 : 76, lineHeight: 1.1 }}>
{article.title}
</div>
</div>
),
{ ...size, fonts: [{ name: 'Inter', data: font, weight: 600, style: 'normal' }] },
)
}The Open Graph tags that connect the image
Platforms find the image through meta tags in the page's head. The image address must be absolute, including https:// and the domain, because the crawler reads it from outside your site. Declaring the width and height helps some platforms lay out the preview before they have downloaded the image, and the alt text describes it for people using screen readers.
<meta property="og:title" content="How to fix gradient banding" />
<meta property="og:description" content="Why gradients show stripes, and four fixes that work." />
<meta property="og:image" content="https://example.com/guide/gradient-banding/opengraph-image.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="The words How to fix gradient banding on a violet gradient" />
<meta name="twitter:card" content="summary_large_image" />twitter:card asks X for the large image layout.
Open Graph 1200 × 630
1200 × 630

LinkedIn link 1200 × 627
1200 × 627

X post 1600 × 900
1600 × 900
Caching and testing OG images
Platforms cache previews, sometimes for a long time. If you change an image but keep its address, people may keep seeing the old one. Add a version to the address, such as ?v=2, when the design changes, or ask the platform to fetch the page again. For on-request images, send cache headers so your server and any CDN keep the result.
- Paste the page into LinkedIn's Post Inspector to see the preview and refresh its cache.
- Use Meta's Sharing Debugger for Facebook, which can also re-fetch a page.
- Paste the link into a draft post on X, or a private chat in Slack or WhatsApp, to see the real preview without sending anything.
- Open the image address directly in a browser to confirm it returns a PNG, at the right size, without a login.
Treat OG images as part of any launch: they are on the list in our launch day graphics checklist, and the full set of formats is in social media image sizes. If you design your previews in Gradiently, its API can render a saved design as an exact 1200 × 630 PNG, which suits pipelines and AI agents that make images for you.
Questions people ask
What is a dynamic OG image?
It is an Open Graph link preview image generated automatically for each page, usually from the page's title and data on a consistent branded template, rather than designed by hand.
What size should an OG image be?
1200 × 630 pixels is the standard. Keep important words away from the edges, because some apps show a smaller or cropped version.
Why is the old preview still showing after I changed my OG image?
Platforms cache preview images per URL. Change the image address, for example with a version query, or use the platform's inspector or debugger to fetch the page again.
Should I generate OG images at build time or on request?
Build time is cheapest and suits pages that rarely change. Generate on request for pages whose data changes, and cache the result so it isn't redrawn for every visit.
Does og:image need an absolute URL?
Yes. Use the full address including https and the domain, because crawlers read the tag from outside your site.
Written by Gradiently
The team behind Gradiently, a design tool built around Marks: living gradients that make everything you design look like yours.
See our profile


