Screenshot API or image templates: which one for OG images?

A screenshot API opens a URL in a real browser and returns an image of what it shows. An image template API takes a layout you designed once — HTML and CSS, or a visual editor — fills in the fields you send (title, author, price) and returns the image. For Open Graph images, templates are usually the better tool: they are designed for 1200×630, legible at thumbnail size, and only change when their fields change. Screenshots win when the page itself is the point.

That is the whole answer; the rest of this guide is the detail behind it, with code for both.

How they differ in practice

The middle row decides most cases. A Facebook or LinkedIn feed shows a link preview roughly 500 pixels wide; a 1280-pixel screenshot of an article page scaled to that width turns 16-pixel body text into about 6 pixels. The image is technically correct and practically unreadable.

When a screenshot is the right og:image

• The page is visual by nature: a dashboard, a chart, a status page, a landing page you want to show off, a design portfolio item.
• You preview someone else's site: link directories, bookmarking tools, "what does this page look like" features, archives. You have no fields to put in a template — only a URL.
• Visual regression or monitoring: comparing a page with itself over time.
• No time to design a card: a screenshot of the hero section is better than no image at all.

For those, ask for a viewport close to the card shape — 1200×630 if the page reads well at that size — instead of a default desktop viewport, and hide what does not belong in a preview:

curl -X POST "https://shareglint.com/v1/screenshots?wait=true" \
  -H "Authorization: Bearer $OG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://status.example.com",
    "viewport_width": 1200,
    "viewport_height": 630,
    "block_ads": true,
    "hide": ["#cookie-banner", ".chat-widget"],
    "wait_for": ".status-grid",
    "format": "png"
  }'

wait_for waits until the selector exists, which matters for pages that render their content with JavaScript after load. A failed page (4xx/5xx, timeout, a private address) comes back as status: failed with a reason and costs nothing.

Without a server, the same capture works as a signed URL you can put straight into og:image or an <img>: https://shareglint.com/s/acc_…png?url=https%3A%2F%2Fstatus.example.com&viewport_width=1200&viewport_height=630&s=… — the signature is computed exactly like the image URLs in the API docs.

When a template is the right og:image

• Blogs, docs, changelogs, product pages, job posts, events — anything with a title and a few facts that should be readable in a feed.
• Many pages with one look: a template keeps every card on-brand without anyone opening a design tool.
• You want caching to work: the image is a function of its fields. Same title, same file — no re-render, no quota.

curl -X POST "https://shareglint.com/v1/images?wait=true" \
  -H "Authorization: Bearer $OG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "template": "blog-og",
    "modifications": {
      "title": "We moved our status page to static hosting",
      "author": "Ana Ruiz",
      "site": "status.example.com"
    }
  }'

Long titles are the main failure mode of templates. A good template shrinks text to fit its box instead of overflowing; in Shareglint that is the data-autofit attribute, and every built-in template uses it.

The hybrid: screenshot your own OG route

A common middle path is to build a dedicated, unlisted route on your own site — /og/posts/42 — that renders a 1200×630 card in your own HTML and CSS, then screenshot that route. You get template-like output from your own codebase, with your fonts and components.

It works, with three costs to plan for: the route is public (anyone can render any card by changing the ID, so do not expose drafts), your page must be fast and stable enough to screenshot every time, and you now maintain both the route and the screenshot job. If you are going to write the card in HTML anyway, sending that HTML to a template API as the template itself removes the route and keeps the same markup — it is the same idea without the public endpoint.

What it costs

Entry-level prices for dedicated screenshot APIs, from their public pricing pages (checked 2026-10-24):

In Shareglint screenshots and template images share one quota: a viewport screenshot uses 1 render, a full-page one 2, and the same URL with the same options within 24 hours returns the existing file for free. The Starter plan is $9 a month for 2,000 renders; the Free plan is 100 a month with a small badge.

Be fair to the dedicated services: ScreenshotOne, Urlbox and ApiFlash have far more capture options than we do — geolocated browsers, full ad-blocking lists, scrolling video, element extraction. If screenshots are your core product, use one of them. One key and one quota for both screenshots and templates is the reason to use ours.

A decision you can make in ten seconds

1. Does the image need to show what the page looks like? Screenshot.
2. Does it need to say what the page is about, readably, in a feed? Template.
3. Do you only have a URL, not structured data? Screenshot — or auto-generated cards that read the page's title and description into a template.
4. Do you need the same image every time for the same content? Template.

Most sites end up with templates for their own pages and screenshots for anything external or visual. Both answers are fine; the wrong one is a 1280×800 screenshot of an article used as the share image for that article.