3 Ways to Auto-Generate Open Graph Images in 2026

There are three ways to generate Open Graph images automatically: point your og:image meta tag at a live render URL, generate the image once at publish time with an API call, or wire a no-code automation from your CMS. All three use one 1200 x 630 template with dynamic text, and all three take under an hour to set up.

Here's the situation that makes this worth an hour. Every page on your site already has an Open Graph image, whether you chose it or not. Share a link in Slack, LinkedIn, or WhatsApp and something shows up in that preview box. For most sites it's the same generic logo on every single page.

Automate it instead. One template, and every blog post, product page, or job listing gets its own preview with its own title baked into the image. Nobody opens Figma. Nobody exports 400 PNGs.

Let's walk through each method, when to use it, and the trade-offs the tutorials usually skip. (I'll be honest about the one everyone recommends that quietly eats your API quota.)

What is an open graph imageWhat Is an Open Graph Image?

An Open Graph image is the preview image social platforms and chat apps show when someone shares your link. The Open Graph protocol defines it as the og:image property, declared in your page's HTML with a meta tag:

<meta
  property="og:image"
  content="https://yoursite.com/images/my-post-preview.png"
/>

The standard size is 1200 x 630 pixels, which matches Facebook's recommended minimum and renders sharp on LinkedIn, Slack, and X. The pitch is simple: the preview image is the first thing people see before they decide whether your link is worth opening, and a page-specific image with the actual title on it beats a cropped logo every time.

The problem is scale. Ten pages, fine, make them by hand. Four hundred blog posts? You need automation.

First build the template one timeFirst, Build the Template (One Time)

All three methods below share the same starting point: a template with dynamic fields.

1. Sign up at app.imejis.io (free, no card needed)
2. Create a design at exactly 1200 x 630 px. The dimension is fixed per template, which is exactly what you want here since OG images are always the same size
3. Add your background, logo, and a text component for the post title
4. Mark the title component as dynamic so the API can override it
5. Grab the design ID

Five minutes, honestly. Or start from an OG image template and skip most of it. If you'd rather see this flow end to end for a blog specifically, we have a dedicated use-case walkthrough.

Now the three ways to wire it up.

Method 1 a live render url in the meta tagMethod 1: A Live Render URL in the Meta Tag

The fastest possible setup. Imejis.io renders images through a GET request, so a URL like this returns a finished PNG:

https://render.imejis.io/v1/YOUR_DESIGN_ID?dma-api-key=YOUR_KEY&title.text=My+Post+Title

Drop it straight into your meta tag and you're done. No storage, no build step:

<meta
  property="og:image"
  content="https://render.imejis.io/v1/YOUR_DESIGN_ID?dma-api-key=YOUR_KEY&title.text=How%20We%20Cut%20Costs%2040%25"
/>

Every time a platform scrapes your page, the image renders fresh with whatever data is in the URL.

Where this shines: data that changes. Think live pricing, event countdowns, stock levels. The preview is never stale.

The trade-offs, and they matter:

• Each scrape is an API call. Facebook, Slack, LinkedIn, and every other unfurler hits that URL independently, and each render counts against your monthly quota. A post that gets shared around can burn calls you didn't plan for.
• Your API key is visible in the URL. Imejis.io keys are scoped to rendering only, so nobody can touch your account with one. But anyone who views source can render images on your quota.

For a personal blog on the free tier's 100 calls, that math can turn against you fast. Which brings us to the method we'd actually recommend for most sites.

Method 2 generate at publish time recommendedMethod 2: Generate at Publish Time (Recommended)

Instead of rendering on every scrape, render once when content is published, store the file, and serve the stored copy. Your og:image points at your own hosting, your key stays server-side, and a viral post costs you exactly one API call.

Here's the whole thing in Node.js:

import fs from "fs/promises"
 
async function generateOgImage(post) {
  const res = await fetch(
    `https://render.imejis.io/v1/${process.env.OG_DESIGN_ID}`,
    {
      method: "POST",
      headers: {
        "dma-api-key": process.env.IMEJIS_API_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        title: { text: post.title },
        category: { text: post.category },
      }),
    }
  )
 
  // The response IS the image. No job ID, no polling, no webhook.
  const image = Buffer.from(await res.arrayBuffer())
  await fs.writeFile(`./public/og/${post.slug}.png`, image)
}

That comment isn't a throwaway. Most image APIs make you create a render job, then poll or wait for a webhook to get the result. Imejis.io returns the image binary in the response itself, typically in under 2 seconds, so this works inside a build script, a CMS publish hook, or a serverless function without any orchestration.

Then your page template just does:

<meta property="og:image" content="https://yoursite.com/og/my-post-slug.png" />

Where this shines: basically everywhere. Blogs, docs sites, e-commerce catalogs, job boards. Static content gets a static image, generated by a robot instead of a designer.

The trade-off: you need somewhere to run the code, whether that's your build pipeline or a small function. If your stack is Next.js, we're publishing a dedicated guide to the App Router version of this pattern next week.

Method 3 no code at allMethod 3: No Code at All

No build pipeline? If your content lives in a CMS, Airtable, or Google Sheets, you can wire the whole flow without writing anything.

The shape is always the same:

1. Trigger: new row, new CMS entry, new product
2. Action: HTTP request to the Imejis.io render URL with the title mapped from the trigger
3. Store: save the returned image to your media library, Drive, or back into the row

Zapier, Make.com, and n8n all handle this with their built-in HTTP/webhook actions, and the GET-style render URL makes the request dead simple to configure: it's just a URL with your fields substituted in. Airtable users can even add a button field that fires the render on click.

Where this shines: marketing teams who own the blog but not the codebase. Set it up once, and every new entry gets its OG image with zero developer time.

The trade-off: automation platforms have their own subscription costs and their own learning curve. And you'll still want a developer to add the meta tag pointing at wherever the images land.

Which method should you pickWhich Method Should You Pick?

Our honest take: start with Method 2 if you can run code, Method 3 if you can't. Save Method 1 for the specific pages where live data in the preview is genuinely the point.

Test before you shipTest Before You Ship

Two free tools make this painless:

• OG Image Tester shows you exactly how your page unfurls on each platform
• Meta Tag Generator writes the full set of OG and Twitter tags if you're starting from scratch

Also worth knowing: platforms cache scraped previews aggressively. If your image doesn't update after a change, run the URL through Facebook's Sharing Debugger or LinkedIn's Post Inspector to force a re-scrape.

Getting startedGetting Started

As of July 2026, the free plan's 100 API calls per month cover a real blog using the generate-at-publish method: that's 100 new or updated pages monthly before you'd pay anything. Paid plans start at $14.99/month for 1,000 calls when you outgrow it.

Build the 1200 x 630 template once, pick the method that fits your stack, and stop shipping pages with a generic logo in the preview box. For the broader API picture beyond OG images, our image generation API guide covers formats, fonts, and bulk generation. And if you're comparing tools first, see the best OG image generators roundup.