How to Create an Open Graph Image (2026)

Why OG Images Actually Matter

The first thing to understand is that the OG image isn’t a decoration — it’s advertising space that other people control for you. When someone shares your article, a link preview card takes up a chunk of the feed or chat they’re posting in. On Twitter, that card is roughly a third of a typical scrolled screen. On LinkedIn, it’s about half. On Slack, it’s often the only thing someone sees before deciding whether to click. Every share of your URL is, in effect, a little ad for the content — and the OG image is the hero asset of that ad. If you designed it, it reads as intentional, professional, and clickable. If you didn’t, it reads as grey-rectangle lazy.

Multiple studies on social CTR have shown that link previews with a designed image get meaningfully higher engagement than link previews with a scraped or default image. The size of that effect varies by platform and audience, but the direction is consistent: better cards drive more clicks. The reason is simple attention economics. A feed is a scrolling list of hundreds of objects competing for a glance; the ones that catch the eye get the click. A grey rectangle does not catch the eye. A well-designed card with legible typography, a strong gradient or color, a recognizable logo, and a readable headline does.

The second thing to understand is that the OG image is once-and-done infrastructure. You design it, you set the meta tags, and from that point forward every share of that page carries the card with it — forever, unless you update the page and re-scrape. There’s no ongoing cost, no per-share fee, no platform-by-platform variant to maintain (if you get the dimensions right). Compared to almost any other marketing tactic, the ROI on “spend 10 minutes designing a good OG image” is absurd.

The third thing to understand is that the OG image also affects AI-assistant link previews now. When someone asks ChatGPT, Claude, or Perplexity to summarize a URL, the assistant often renders a preview card with the OG image. That card is increasingly where a meaningful share of “first impressions” of a page happens. The OG image isn’t just for humans anymore; it’s for the LLMs helping humans decide what to read.

The 1200×630 Standard

Facebook, LinkedIn, and Twitter/X all render large link preview cards at a 1.91:1 aspect ratio, and they all accept 1200×630 pixels as the canonical source. This is the number to design for. Smaller sizes get upscaled and look pixelated on high-DPI displays. Larger sizes get downsampled at the platform’s processing stage, which is fine but means you’re exporting more bytes than necessary. Different aspect ratios get letterboxed (bars added) or center-cropped (edges cut off), and neither behavior is under your control.

Below 600×315, Facebook falls back to the small-square preview — a card roughly a third the visual size of the large card. This is the worst possible outcome because you’ve given the platform enough to not auto-scrape but not enough to render the hero treatment. If your OG image is smaller than 600×315, you’re actively sabotaging your preview.

Slack, Discord, iMessage, WhatsApp, Teams, Signal, and most other chat clients also render the 1.91:1 card when available and fall back to a smaller thumbnail otherwise. The exact crop behavior varies a bit (Slack crops slightly tighter on the right, iMessage adds more padding), but if your source is 1200×630, it will look correct in all of them.

A common trap: designing a square OG image because “IG uses square.” Instagram doesn’t use your OG image — it doesn’t unfurl links at all. The square format is for your Instagram feed post, which is a different piece of content you produce separately. For the OG image, 1200×630 is the answer everywhere.

File format: PNG for most cases (lossless, handles text crisply); JPG if the image is photograph-dominant and you want smaller file size. Avoid WebP for OG images — some older social crawlers still don’t handle it correctly. File size under 8MB to stay well within every platform’s cutoff (Twitter’s is 5MB, Facebook’s is 8MB, LinkedIn’s is 5MB, Slack is 15MB). Under 300KB is better; most well-designed OG images with text-over-gradient come in well under 200KB.

Anatomy of a Good OG Image

The good OG image has three parts: a hero text block, a supporting visual or pattern, and a byline with brand identifiers. The text block is the hero because most link previews are scrolled past in a fraction of a second — the text has to read in that fraction. That means large type (typically 60–100px at 1200×630), strong contrast with the background, and a line count of one or two. Paragraph-length OG images don’t work because nobody reads a paragraph at that scale.

The background is usually the next most important decision. Gradients work well because they add visual interest without competing with the text. Solid colors work if your brand has a strong one. Photographic backgrounds are risky because they often have busy areas that clash with text overlays — if you use one, you almost always need a scrim (a dark semi-transparent overlay) to make the text legible. Patterns (subtle dots, grids, noise) add texture without demanding attention.

The byline is the identity anchor — a small lockup of logo, site name, and author or section name. This lives in a corner or along the bottom edge and gives the card brand recognition. On a feed full of unrelated posts, the byline tells the scroller “this is from [site] which I know and trust.” If your brand has a strong logo, the byline is where to use it. If not, a simple site-name-in-display-font works fine.

Color contrast is where most homemade OG images fail. The test: squint at the card from three feet away. If the text loses legibility, the contrast is wrong. WCAG AA requires 4.5:1 contrast for normal text and 3:1 for large text; for OG images, the text is large enough that 3:1 is the floor, but 4.5:1 is what you should aim for because mobile previews are small and the text reads as normal-size. Bright backgrounds need dark text (#0B0D17 or near-black); dark backgrounds need white or near-white text.

The four layout patterns that work for almost any content: centered (text blocks centered vertically and horizontally, byline floating at bottom — good for single-topic pages, editorial content), left-aligned (text block anchored to the left, byline at the bottom-left — good for article headlines with strong personality), split (text block on the left, brand or logo mark taking up the right half — good for product pages and brand-forward content), and minimal (small logo at top, massive headline in the middle, small byline at the bottom — good when you want the headline to be the only thing that registers). Pick one that matches the content type and stick with it across the site; consistency is a brand signal.

Installing the Meta Tags

Once you have the PNG, host it somewhere public — your CDN, your site’s /public or /static folder, or a blob service. The URL must be publicly fetchable without authentication (no signed URLs, no Cloudflare Access, no basic auth) because social platform crawlers don’t log in. Test the URL by pasting it into an incognito window — if the image loads, it’s accessible.

Then add these meta tags to the page’s :

The explicit width and height tags matter. Some older Facebook crawler versions fall back to small-card rendering if the dimensions aren’t declared, even if the image is actually 1200×630. Declaring them is cheap insurance.

The twitter:card value of summary_large_image is what makes Twitter/X render the hero card instead of the tiny inline thumbnail. Without this meta tag, Twitter defaults to the small card regardless of image size. You want the large one.

The og:image:alt tag provides accessibility text for screen readers and is also used by some AI assistants to describe the image. Write it the way you’d describe a photo to someone over the phone — not “OG image for blog post about X”, but “Title card reading [headline] on a blue gradient background with [site] byline in the corner.”

For pages built with a framework — Next.js, Astro, SvelteKit, Nuxt, Eleventy, Hugo — most have built-in head components that accept an og object. The exact syntax varies but the resulting HTML is the same. Test by viewing source on the deployed page and confirming the meta tags are present and pointing to the right URL.

Debugging Platform Caches

The most frustrating thing about OG images is the caching. When someone shares your URL for the first time, the platform scrapes the page, caches the OG data (including the image), and uses that cache for every subsequent share of the same URL. If you later update the image, the cached version keeps serving until the cache expires — sometimes weeks later. This means testing a new OG image by sharing it to your own Twitter and seeing the old version is completely normal.

The fix is manual cache busting with each platform’s debug tool. Facebook’s Sharing Debugger (developers.facebook.com/tools/debug) accepts any URL and forces a re-scrape when you click “Scrape Again.” After re-scraping, the updated OG image appears in Facebook link previews immediately. Twitter used to have a Card Validator with similar behavior but retired it in 2023; posting and deleting a tweet with the URL is now the workaround (the post-and-delete action forces Twitter’s crawler to re-fetch). LinkedIn’s Post Inspector (linkedin.com/post-inspector) accepts a URL and re-scrapes on demand, identical to Facebook’s.

Slack’s unfurl cache is shorter — about 24 hours — and has no public tool for forcing a re-scrape. The workaround is changing the URL with a trivial query string (?v=2) which Slack treats as a new URL and scrapes fresh. This is hacky but works. Discord and iMessage follow similar patterns.

If a debug tool claims to see the new image but actual shares still show the old one, the problem is usually that the HTML page itself is cached by a CDN (Cloudflare, Fastly) and the crawler is seeing the old meta tags. Purge the HTML cache, then re-run the debug tool. If you’re using a static site generator, verify the new page has actually deployed — a common gotcha is the meta tags being updated in code but the build not running successfully, so the deployed page still has the old tags.

One last trap: if your site sits behind an authentication wall on staging environments but the domain is correct, the platform crawler may fetch the auth-wall page and scrape its OG image instead of your actual page’s. Either block crawlers from staging with a robots.txt disallow or make the page publicly viewable. For production, don’t put meta-tag changes behind auth.

The 60-Second Workflow

Step 1 — Pick the layout. Centered for editorial content, left for articles with personality, split for product or brand-forward pages, minimal when you want the headline to be the only thing that registers. If you’re not sure, start with left-aligned — it works for 80% of use cases.

Step 2 — Write the headline. Keep it under 60 characters. This is the piece of the card that does 90% of the work, so iterate until it reads as compelling, not just descriptive. “How to write an OG image” is descriptive; “Your link previews are bad and you can fix them today” is compelling. Both are valid; know which one you’re writing.

Step 3 — Pick the background. If your brand has a defined palette, match it. If not, a medium-dark gradient (blue, purple, teal) with light text is the safe default. Avoid light-on-white or dark-on-black; they fail the squint test.

Step 4 — Add the byline. Site name, optionally your name, optionally a logo. Keep it small — the byline should be identifiable without competing with the headline. If your logo is a simple wordmark, swap it in; if it’s a complex lockup that doesn’t scale down, use just the wordmark or a monogram.

Step 5 — Export as PNG at 1200×630 (or 2400×1260 if you want retina resolution — the platforms don’t need it but it doesn’t hurt). Host it somewhere publicly reachable. Install the meta tags. Run each platform’s debug tool to confirm the card renders correctly. Done.

Repeat per page type, not per page. Most sites have 3–4 page types (homepage, blog post, product, author profile) and can use templated OG images for each. A blog post can have a templated header-with-title OG where the title swaps in dynamically; a product page can have a templated product-shot-plus-name. This is how Vercel, Linear, GitHub, and Stripe produce OG images at scale — they generate them at build time from a template.