Developer Guide

What Is an OG Image and Why Every Blog Post Needs One

July 27, 20268 min read

What Is an OG Image and Why Every Blog Post Needs One — ThumbAPI Blog

Every time a link is shared on Facebook, LinkedIn, Slack, Discord, Twitter/X, iMessage, WhatsApp, or a preview embed anywhere on the web, the platform grabs a rectangle image from the page and shows it above the title. That image is the Open Graph image — the OG image. It's the piece of the share preview that decides whether the link gets clicked or scrolled past.

Most blogs still don't ship one per post. This guide is the developer-focused breakdown: what an OG image actually is, the specs that matter in 2026, why the default (no image, or a stale one) costs you clicks, and how to automate one per post so the design step stops being the reason.

Prerequisites

A blog, landing page, or any site whose links get shared on social platforms
Some access to the site's <head> (either through a CMS field or your framework's metadata API)
20 minutes to read this and set up one per post

You don't need a designer, a Photoshop licence, or a template library. The whole spec is a rectangle at a specific size with a specific meta tag, and the automation stack for shipping one per post is smaller than most teams assume.

What an OG Image Actually Is

An OG image is a still image referenced from your page's <head> via the Open Graph protocol — a metadata spec Facebook introduced in 2010 and every major platform now uses. The tag looks like this:

<meta property="og:image" content="https://example.com/covers/my-post.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />

When a link is shared, the receiving platform's crawler hits the URL, parses the <head>, finds the og:image, downloads it, and renders it as part of the share preview card. No image? Most platforms fall back to whatever they can find in the DOM — usually a broken thumbnail or a favicon-sized crop of a random image.

The spec:

Size: 1200×630 pixels. This is the standard that Facebook, LinkedIn, and Slack render at. Twitter/X uses the same for summary_large_image cards.
Aspect ratio: 1.91:1. Any material deviation gets cropped by the platforms.
File size: under 5 MB. Ideally under 200 KB — every scraper has a timeout.
Format: PNG or JPG universally supported. WebP works on modern platforms; PNG is the safest legacy choice.
Meta tag: og:image (Open Graph), plus twitter:image and twitter:card=summary_large_image for Twitter/X.

Every other Open Graph property (og:title, og:description, og:type, og:url) matters too, but og:image is the visual anchor.

Why It Matters — the CTR Case

The OG image is often the single largest visual on a social share card. A tweet with a large image card takes up 3–4× the vertical space of one without. A LinkedIn share with an OG image gets pushed higher in the feed algorithm's ranking. A Slack preview with a rich card gets more clicks than a bare URL.

Public studies from BuzzSumo, Facebook's own social API team, and various publisher A/B tests all land in the same range: posts with a proper OG image get 2–3× the click-through rate of posts without one. Adjust for the fact that most publishers are shipping some OG image (even if it's the same generic cover across every post), and the delta between a unique per-post OG image and the default is still meaningfully positive — typically 20–40% CTR lift on high-engagement platforms.

The math flips when the OG image is bad. A stretched logo, a stock photo that has nothing to do with the post, or a template that looks the same across every post gives the eye no reason to stop. The image is either an asset or a liability — there's no neutral middle.

The Specs That Actually Matter in 2026

Beyond the raw dimensions, five things separate an OG image that works from one that doesn't:

Text legibility at preview size. Most OG previews render at 400–500 pixels wide on desktop and 320–380 on mobile. Any text below about 60px on the source image becomes illegible. Two to four bold words is the working size — same rule as YouTube thumbnails.
Focal point in the safe area. Some platforms crop OG images. Keep critical content in the middle 80% of the frame — anything at the edges may get cut on Discord, iMessage, or older Slack renderers.
Contrast against social feed backgrounds. LinkedIn, Twitter/X, and Facebook default to white/light backgrounds; Slack and Discord default to dark. An OG image that reads well on both is what you want. Avoid palettes that dissolve into one background or the other.
Meaningful, not decorative. A stock photo of a keyboard for a post about React hooks is worse than no image. The visual should tell the reader something about the post — a chart, a screenshot, an illustration of the concept.
Freshness. If your OG image is a template designed 18 months ago that never gets refreshed, it starts looking dated to audiences who've seen 10,000 similar templates. This is why static template-based OG images age out faster than most teams realise.

The Common Failure Modes

Four patterns cover ~90% of OG-image mistakes:

No OG image at all. The platform falls back to whatever it can scrape, or renders a plain link with no preview. Instant CTR floor.
The same generic cover on every post. Better than nothing but only slightly. The eye trains itself to skip repeated patterns.
Wrong aspect ratio. Uploading a square Instagram graphic to og:image gets it either letterboxed or cropped badly. Every platform expects 1.91:1.
Broken absolute URL. og:image must be an absolute URL (https://example.com/img.png), not a relative one (/img.png). Platforms won't resolve relative paths and the preview breaks silently.

Debugging tip: paste any URL into Facebook's Sharing Debugger or LinkedIn's Post Inspector and it'll show you exactly what the OG scraper is seeing.

How to Ship an OG Image per Post — the Automated Path

The manual version — open Figma, drop the title into a template, export a 1200×630 PNG, upload it to your CMS, and set the OG meta tag — takes 10–20 minutes per post. For any blog shipping more than a couple of posts a week, that's the reason OG images are still missing.

The automated version is a single API call per new post. The pipeline shape:

CMS publish webhook fires (Ghost, WordPress, Sanity, Contentful, Notion, or a Next.js publish hook — anything with a trigger works).
Extract the title from the payload.
Call a thumbnail generation API with the title and format: blogpost (1200×630 — matches the OG spec).
Save the returned image to your CDN or object storage.
Set the OG meta tag on the post to the absolute URL of the saved image.

That's the whole loop. For the copy-pasteable Next.js version, the Next.js OG images use case has a Route Handler + build-script variant end to end. For the framework-agnostic version (Ghost, WordPress, Sanity, Contentful), the automated blog covers use case covers the webhook shape for each CMS.

The specific tool sitting in the middle of that loop for image-only workloads is ThumbAPI — one endpoint takes a title, returns a 1200×630 PNG or WebP, no template stage. The OG image API landing page has the format-focused hub if you want the pricing and API surface in one place.

The Framework-Specific Meta Tag Setup

The og:image tag lives in your <head>. Every framework has an idiomatic way to set it.

Next.js App Router:

export const metadata = {
  openGraph: {
    images: [{ url: 'https://example.com/covers/my-post.png', width: 1200, height: 630 }],
  },
  twitter: {
    card: 'summary_large_image',
    images: ['https://example.com/covers/my-post.png'],
  },
};

Astro:

<meta property="og:image" content={coverUrl} />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content={coverUrl} />

WordPress: Yoast, Rank Math, and All in One SEO all handle this automatically once you set the post's featured image. Ship a proper featured image and the OG tags follow.

Ghost: Same — set the post's feature image and Ghost renders the OG tags automatically.

What About Dynamic OG Images

Some teams route OG images through a serverless "generate on request" endpoint (Vercel OG, Next.js ImageResponse, or Cloudflare Workers with Puppeteer). The upside is zero storage — every OG scrape triggers a fresh render.

The downsides worth knowing:

Cold-start latency. The first scraper to hit a URL waits for the render. Facebook's crawler doesn't retry aggressively — a slow response can mean no preview.
Rendering cost per share. A viral post that gets scraped 10,000 times renders 10,000 images. Cache-aggressive setups help, but the cost sneaks up.
Design ceiling. Dynamic renderers are usually stuck with a template — you're back to "same visual across every post," just implemented on the server.

The generate-once-and-cache approach (a real image URL saved to your CDN) is simpler, faster for the scraper, and — with an AI generation tool — produces unique-per-post OG images without a template. That's the pattern most content-heavy teams have converged on in 2026.

The Under-the-Hood Bit

If you want to see the OG image spec in action, curl any well-optimised blog post and grep the <head>. Every major publisher (The Verge, Stripe, Vercel, GitHub) does the same three things: set og:image to an absolute URL, include og:image:width and og:image:height, and ship a twitter:card=summary_large_image alongside. Miss any of those three and one platform or another drops the rich preview and shows a plain link.

Ship OG Images Automatically Today

Every blog post you publish without a proper OG image is a click lost on every share. The manual fix is real design work per post. The automated fix is one API call per post inside your publish webhook.

Start free with 50 credits per month — enough to test the pipeline against your last 5 posts and check the OG preview against a real Facebook or LinkedIn share. The OG image API landing page has the format-focused surface, and the quickstart is the five-minute version if you want to wire the first call today.

Written by

Aldin Kozica

Full-stack developer from Bosnia and Herzegovina. I built ThumbAPI because I kept watching content teams waste hours on thumbnail design when the patterns are predictable enough to automate. The API is the tool I wished existed when building content pipelines for my own projects.

Continue Reading

Automating Content Creation: A Developer's Guide

A practical, developer-focused guide to automating content creation pipelines with APIs, including thumbnail generation, scheduling, and integration examples.

Faceless YouTube Thumbnail Strategy — What the Data Says in 2026

A data-grounded look at what actually works for faceless YouTube thumbnails in 2026 — palette, typography, layout, and the patterns pulling clicks in each niche. Plus the automation stack running behind the top channels.

The Math of Automated SEO: How We Build Programmatic Pipelines in 2026

Why manual writing fails at scale, how programmatic SEO pipelines work under the hood, and what the raw math says about indexing, traffic, and dev workflow.

Thumbnail API vs Manual Design — Real Cost Comparison With Numbers

The real cost comparison between designing thumbnails manually (Canva, Figma, Photoshop, freelancers) and calling a thumbnail API — time, dollars, and CTR trade-offs, broken down for 30, 100, and 1000 videos per month.

Generate Thumbnails With an API

Try ThumbAPI free. 50 credits per month, no credit card required. One API call, production-ready output.

Try It for Free