GUIDE

og:image Generator: The Meta Tag, the Spec, and Getting It Right

A spec-level look at the og:image meta tag family — required versus optional properties, and the syntax mistakes that quietly break previews.

August 16, 20266 min read

og:image is a single meta tag, but it belongs to a small family of related properties, and most of the og:image generator tools people reach for skip past the spec-level detail — which properties are required, which are optional but strongly recommended, and where the exact syntax trips people up. This post treats og:image as what it actually is: part of the Open Graph protocol, with defined structured properties, not just an arbitrary image URL you drop into the head.

The base tag

The only strictly required piece is og:image itself, holding an absolute URL to the image:

<meta property="og:image" content="https://example.com/preview.png" />

That alone is enough for most crawlers to attempt a fetch and render a card. But "enough to work" and "reliable" are different bars, and the gap between them is exactly the structured properties most implementations leave out.

og:image:width and og:image:height

These two properties tell the crawler the image's actual pixel dimensions before it fetches the file:

<meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" />

Without them, some crawlers have to download the entire image just to determine its dimensions before they can lay out the card, which slows down the unfurl and, on a slow-loading image or an overloaded server, occasionally causes the crawler to give up before it ever displays anything. Declaring the dimensions up front lets the crawler reserve the correct card layout immediately. It's a small tag pair that's easy to skip and has a real effect on unfurl reliability under load.

og:image:alt

og:image:alt is the accessibility-facing property — alt text describing the image for screen readers and for platforms that surface it, distinct from any og:description text:

<meta property="og:image:alt" content="Dashboard showing weekly click analytics by referrer" />

It's optional in the sense that most crawlers won't reject a card for lacking it, but it's one of the fields Site Audit tools specifically check for, and skipping it consistently across a site is a real accessibility gap, not just a minor omission.

og:image:type and og:image:secure_url

Two less commonly used but spec-defined properties round out the family. og:image:type declares the MIME type explicitly (image/png, image/jpeg) rather than leaving the crawler to infer it from the URL's file extension, which matters when the URL doesn't have a clean extension — a dynamically rendered image behind a query-parameterized path, for instance. og:image:secure_url is a holdover from when HTTP and HTTPS needed to be declared separately for a resource; on a modern all-HTTPS site it's rarely necessary, but some older crawler implementations still check for it.

Multiple images

The Open Graph spec technically supports multiple og:image tags on one page, letting a crawler choose among options:

<meta property="og:image" content="https://example.com/wide.png" /> <meta property="og:image" content="https://example.com/square.png" />

In practice, most crawlers just take the first one they encounter and ignore the rest, so this is more useful as a fallback mechanism for older or unusual crawlers than as a reliable way to serve different platforms different images. If you need genuinely different images per platform, that's better handled by serving different meta tags to different user agents server-side, not by relying on multi-image fallback behavior that isn't consistently implemented.

Common syntax mistakes

Relative URLs (content="/images/preview.png") — many crawlers won't resolve these against the page origin and will simply fail to fetch the image
Mismatched declared dimensions — setting og:image:width to 1200 when the actual file is 800px wide, which can cause a crawler to render a stretched or oddly cropped card
Placing the tags outside <head> or after a client-side rendering boundary, so a crawler that doesn't execute JavaScript never sees them
Using property instead of name, or vice versa — og:* tags use property, not name; mixing them up causes some parsers to silently ignore the tag
Serving the image behind auth or a CORS policy that blocks the crawler's user agent specifically, even though it loads fine in a signed-in browser

How og:image relates to og:title and og:description

og:image doesn't render in isolation — it's shown alongside og:title and og:description in most card layouts, and the three are meant to work as a set rather than be evaluated independently. A common mistake is optimizing the image without checking how it reads next to the title text that will sit beside or below it. If the image already contains a headline rendered as part of the graphic, and og:title repeats that same headline as text underneath the card, you end up with visual redundancy — the same words appearing twice in slightly different typography, which reads as sloppy rather than deliberate even though each tag is individually correct.

The more deliberate pattern is to decide up front which element carries which information. Some templates put the full headline directly on the image and keep og:title minimal or brand-focused, relying on the image to do the communicating. Others keep the image purely visual — a photo, a color field, a logo — and let og:title and og:description carry all the text, on the logic that og:image text can render inconsistently across platforms with different font rendering, while og:title text renders using each platform's own native card typography and is guaranteed to display legibly. Neither approach is universally correct, but picking one on purpose, and generating both consistently rather than letting them drift independently, produces a noticeably more polished result than treating each tag as its own separate task.

Testing og:image changes without waiting on live crawler caches

Because most platforms cache the metadata they scrape on first fetch, iterating on an og:image tag by editing it and then checking a live share is slow — you're often looking at a stale cached version rather than your actual change, and it's easy to mistake a caching delay for a bug in the tag itself. A faster iteration loop uses a debugging tool that fetches the current live tags directly, bypassing whatever a given platform has cached, so you can confirm a change actually took effect on the page itself before worrying about whether a specific platform has picked it up yet. Separating "did my tag change correctly" from "has this specific platform re-scraped it yet" avoids a lot of wasted debugging time chasing what looks like a broken tag but is really just a caching lag.

This iteration loop matters more than it sounds like a small workflow detail. Teams that don't separate these two questions frequently ship a fix, see no visible change on a live share, conclude the fix didn't work, and revert or rewrite it — when the actual issue was a caching lag on the specific platform they happened to test with. Confirming the tag itself is correct first, independent of any single platform's cache state, avoids that entire category of wasted debugging.

How useopengraph handles the full property set

useopengraph generates the complete og:image property set automatically from a template's render output — width and height come from the actual rendered image rather than a manually entered value that can drift out of sync, and each render is served from an absolute, versioned URL that stays reachable without authentication. Site Audits then check og:image presence and dimensions, alt text, and the related tag set across every crawled page, so a missing og:image:alt or a dimension mismatch shows up as a specific finding rather than something you'd only catch by reading page source by hand.

KEEP READING

OG ImagesSee the feature this post is about.

OG Image Size Guide: The Right Dimensions for Facebook, X, LinkedIn, and SlackThe correct og:image dimensions for every major platform, why 1200×630px became the default, and how to keep text and logos from getting cropped.

What Is an Open Graph Image? A Quick ExplainerA plain explanation of Open Graph images, what the og:image meta tag does, and why it's the difference between a rich link preview and a bare blue link.

Open Graph Tags vs. Twitter Cards: Do You Need Both?Open Graph is the protocol nearly every platform reads by default. Twitter/X has its own twitter:* tags and only falls back to og:* when they're missing. Here's what to actually put on your page.

Twitter Card Types Explained: Summary, Summary Large Image, Player, AppA quick reference for the four twitter:card values — what each looks like, the meta tag to set, and when to actually use it.