Short answer: build an og image generator by pointing a screenshot API at the page you want previewed, then drop the hosted image URL it returns straight into your og:image meta tag. One GET request per page, and no design tool in the loop.
By the end you will have one API call that turns any URL into a hosted Open Graph image, plus the exact meta tags that make it render in every social preview.
The long version matters because most og image generators make exactly one image, by hand, and then quietly go stale the moment the page changes. ScreenshotRender renders the live page instead, so the preview always matches what visitors actually see. Here is the difference, and the single call that produces it.
What is an OG image and why does every page need one?
An OG image is the preview picture that appears when someone shares your link on Slack, X, LinkedIn, Discord, or iMessage, and one <meta> tag in your page's <head> decides what it shows. That tag is og:image, part of the Open Graph protocol.
Open Graph is the shared vocabulary social platforms use to read a page. A handful of tags (og:title, og:description, og:url, and og:image) tell the platform what to put in the preview card so it does not have to guess from raw HTML. The <meta> element itself is plain HTML; the work is filling in the right values. Of those four tags, og:image is the one that does the visual work, and it is the one teams forget.
Skip it and the result is not neutral, it is worse than neutral. The platform either shows a bare text link with no image, or it grabs the first usable picture on the page, which is often a logo, an avatar, or a tracking pixel. Either way the share looks broken next to links that got it right, and you find out after someone has already posted it.
So every page that can be shared needs an og:image. The real question is how to produce one without it becoming a recurring chore.
Why do static OG image generators fall short for real sites?
Static OG image generators fall short because they produce one frozen file with no live connection to the page it represents. Drag and drop tools like opengraph.xyz or a Canva template are fine for a single landing page, but they break down the moment a site has more than a handful of URLs.
Three problems show up, and they compound:
- Drift. You export the image once. Then the headline changes, the price changes, the hero screenshot changes, and the OG image still shows the old version. Nobody re-exports it because nobody remembers it exists.
- Manual work per page. Every new blog post, product page, or docs page needs a human to open the tool, type the title, position the elements, export, and upload. For a site that publishes weekly, that is a standing task with zero product value.
- No automation hook. A drag and drop editor cannot run in your build pipeline. There is no API, no command, nothing CI can call, so the OG image is never part of the same process that ships the page.
The pattern underneath all three is the same: the image is divorced from the page. The fix is to stop treating the OG image as a design asset you make once, and start treating it as something you render from the page itself, every time.
Stop hand-exporting OG images. Generate them from the page.
Point ScreenshotRender at any URL and get back a hosted PNG with cookie banners and ads already stripped, ready to drop straight into your og:image tag.
Try a renderHow do you build an OG image generator with a screenshot API?
You build an og image generator by sending one HTTP GET to a screenshot API with the URL you want previewed, then using the hosted image it returns as your og:image. With ScreenshotRender the whole request is one line you can copy:
https://screenshotrender.com/api/v1/screenshot?apiKey=YOUR_API_KEY&url=https://github.com
Two parameters do the work. apiKey is your sr- prefixed key from the ScreenshotRender dashboard. url is the page you want to capture. Notice there is no fullPage here: an OG image is a single card, not a tall scroll, so you want the default 1280 by 720 viewport capture rather than the entire document. The response is JSON, and the hosted image sits at data.screenshot, a URL you can put directly into your meta tag.
There are two ways to point that url at something worth previewing. The first is the page itself: capture https://github.com or your own marketing page and the preview is a real screenshot of real content. The second is a dedicated template route. You build a page in your own app, say a route that reads a title from the query string and lays it out as a branded card, then point the API at that route. This is the same pattern the well-known OG image services use, except you own the template and ScreenshotRender does the rendering.
If the page or template route is a single page app that hydrates after the first paint, append &wait=2000 so the renderer pauses two seconds before capturing. A timeout value caps the whole request so a slow page fails fast instead of hanging your build. Cookie consent banners, ad overlays, and chat widgets are stripped automatically before every capture, so a screenshot of a live page comes back clean instead of showing a "We use cookies" bar across your link preview.
Test the exact call against your own page in the interactive playground before you wire it into a build step that runs on every deploy.
Once that call works, generating an OG image is no longer a design task. It is one HTTP request, and it runs anywhere an HTTP request can.
What size should an OG image be?
An OG image should be 1200 by 630 pixels. That is the size Facebook, LinkedIn, and X all render as a large summary card, and Facebook's own image guidelines recommend it directly.
A few rules sit around that number. The aspect ratio is roughly 1.91 to 1. The smallest image that still renders as a large card is 600 by 315, and anything smaller drops to a small thumbnail card. You should also declare the dimensions explicitly with og:image:width and og:image:height so the platform can reserve layout space before the image loads, which the Open Graph protocol supports as structured properties.
X reads its own tags on top of Open Graph. Set twitter:card to summary_large_image and twitter:image to your picture, and X shows the same large card, as the X Cards documentation describes. If you only set og:image, X falls back to it, so one image often covers every platform.
One honest detail about the screenshot approach: ScreenshotRender's default capture is 1280 by 720, a 16 by 9 image, not an exact 1200 by 630. That still works as an og:image, because platforms scale and crop the image they are given, and you declare og:image:width and og:image:height as 1280 and 720 to match. If you need a pixel exact 1.91 to 1 card, size your template route to that ratio so the viewport capture lands close, or crop the returned image in your build step. The renderer's job is producing the hosted image from a live page.
When does an automated OG image generator fail?
The screenshot approach has three real limits worth knowing before you put it on every page, because no honest guide claims a method with no edges.
- Login-gated pages. A public screenshot API takes a URL, not a session cookie. If the page you want to preview lives behind authentication, the renderer sees the login screen, not the content. Generate a signed public share URL on the source app and capture that, or build an unauthenticated template route that takes the data it needs as query parameters.
- Pixel-exact dimensions. The capture is 1280 by 720, not an arbitrary size. For most link previews that is fine. If a brand spec demands an exact 1200 by 630 down to the pixel, add a crop step after the render.
- Bot-protected target pages. If the page you capture sits behind Cloudflare, vanilla rendering gets a challenge instead of the page. ScreenshotRender's Stealth Mode handles that, but it starts on the Hobby plan, so a free key pointed at a Cloudflare protected site captures the challenge screen. Template routes you host yourself are not protected, so this only matters when you screenshot someone else's page.
There is also the caching gotcha, which is not a failure of the generator but of the platforms. Facebook, LinkedIn, and X scrape your page once and store the OG image. Change it later and the old one sticks until you force a re-scrape through the platform's debugger, such as the Facebook Sharing Debugger. Build that re-scrape step into your publish flow and the stale preview problem goes away.
For everything else, a marketing page, a blog post, a docs page, a product listing, one GET request per page is the whole generator.
Common questions about OG image generators
How do I create an OG image for my website?
You create an OG image by generating a 1200 by 630 picture, hosting it at a public URL, and referencing that URL in an og:image meta tag inside your page's <head>. The fastest automated way is to send the page URL to a screenshot API like ScreenshotRender, which renders the live page and returns a hosted image URL you drop straight into the tag. That removes the design-tool step and keeps the preview in sync with the page it represents.
What is the difference between og:image and twitter:image?
og:image is the Open Graph tag read by Facebook, LinkedIn, Slack, Discord, iMessage, and most other platforms. twitter:image is X's own tag, used together with twitter:card set to summary_large_image. If you only set og:image, X falls back to it, so a single image often covers both. Setting twitter:image explicitly lets you serve a different picture on X when you want one.
Can I generate OG images dynamically for every page?
Yes. Instead of exporting one file per page by hand, call a screenshot API at build time or on request, passing each page's URL. ScreenshotRender returns a hosted image URL per call, and cached results are served from an edge CDN, so repeated requests for the same page do not re-render. That makes a per-page OG image practical even for a site with thousands of URLs.
Why is my OG image not showing when I share the link?
The most common cause is caching. Facebook, LinkedIn, and X scrape your page once and store the OG image, so a later change is not picked up until you force a re-scrape. Run the URL through the platform's debugger, such as Facebook's Sharing Debugger or LinkedIn's Post Inspector, to refresh it. Other causes are an og:image URL that is not publicly reachable, an image below the minimum size, or the meta tag sitting outside the <head>.
Is there an API to generate OG images automatically?
Yes. ScreenshotRender is a screenshot API: you send a GET request with the page URL and your API key, and it returns a hosted PNG URL rendered from the live page, with cookie banners and ads removed. The free plan includes 100 images a month with no credit card, which is enough to wire OG image generation into a small site end to end before paying for more volume.
The honest verdict: a static og image generator is fine for one landing page you will never touch again. For a real site with pages that change and multiply, the OG image has to be rendered from the page, not drawn once by hand. One screenshot API call does that, it runs in a build step or on request, and the free tier gives you 100 images a month to prove the workflow before you pay for volume.
