Skip to content
Quasar Tools Logo

Open Graph og:image Absolute URL Requirements Explained

Why og:image must be an absolute URL, not a relative path — and how to set it correctly in Next.js, WordPress, plain HTML, and any other stack.

DH
Tutorials & How-Tos14 min read3,200 words

The og:image tag is one of the most impactful meta tags on your page — it's the thumbnail that shows up when anyone shares your URL on Facebook, LinkedIn, WhatsApp, Slack, Discord, or X. But there's one rule that trips up developers constantly: the URL you put in og:image must be absolute. A relative path will silently fail, and your link preview will show no image at all. This guide explains why that requirement exists, what "absolute URL" actually means, and exactly how to set it correctly.

1200×630Recommended og:image sizepx, 1.91:1 ratio
~300 KBRecommended max file sizeFor fast previews
100%Crawlers require absolute URLsRelative paths always fail

What is og:image and why does it matter?

Open Graph is a protocol introduced by Facebook in 2010 that lets you control how a URL appears when shared on social platforms. The `og:image` meta tag defines the preview image — the large thumbnail that draws attention in a feed, a chat message, or a link card. Today it is supported by virtually every platform that renders link previews: Facebook, LinkedIn, WhatsApp, Telegram, Discord, Slack, iMessage, and more.

Without a valid og:image, platforms either show no image at all or attempt to scrape a random image from the page — usually picking something irrelevant or too small to render cleanly. A well-crafted og:image can dramatically increase click-through rates on shared content, making it one of the highest-leverage meta tags you can add to any page.

The basic syntax

og:image in the <head>
html
<meta property="og:image" content="https://example.com/images/article-cover.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="A descriptive alt text for the preview image" />

Note

The `og:image:width`, `og:image:height`, and `og:image:alt` tags are optional companions to `og:image`. Providing width and height lets crawlers render the preview without fetching and measuring the image first, which speeds up link unfurling — especially on WhatsApp and Telegram.

Why og:image requires an absolute URL

When a user shares a link on Facebook, LinkedIn, or WhatsApp, the platform's web crawler visits that URL to read its meta tags. Crucially, the crawler is an independent HTTP client — it has no concept of "which page it came from." When it reads a relative path like `/images/cover.jpg`, it has no base URL to resolve that path against, so it either ignores the tag or throws an error.

An absolute URL, by contrast, is self-contained. It includes the protocol, the domain, and the full path — everything the crawler needs to fetch the image from any context, without relying on the page it just read. This is the reason the Open Graph documentation explicitly states that og:image should be an absolute URL, and it is why every major platform enforces this requirement.

The og:image URL must be an absolute URL. Relative URLs, protocol-relative URLs, and data URIs are not supported.

Open Graph Protocol documentation (ogp.me)

The three URL formats and which ones work

URL FormatExampleWorks as og:image?
Absolute URLhttps://example.com/og.jpg✓ Yes — always works
Protocol-relative URL//example.com/og.jpg✗ No — missing scheme
Root-relative path/images/og.jpg✗ No — no domain
Relative pathimages/og.jpg✗ No — no domain or root
Data URIdata:image/png;base64,…✗ No — not a URL

Warning

Protocol-relative URLs (`//example.com/og.jpg`) look almost correct but will fail. Facebook's and LinkedIn's crawlers do not resolve them. Always use the full `https://` scheme.

What 'absolute URL' actually means

An absolute URL is one that fully identifies the resource's location on the internet, regardless of the context in which it appears. It consists of four components, all of which must be present:

  1. Scheme — the protocol: `https://` (always use HTTPS; HTTP images may be blocked by mixed-content rules on HTTPS pages)
  2. Host — your domain name: `example.com` or `www.example.com`
  3. Path — the location of the file: `/images/og-cover.jpg`
  4. Optional: port — only needed if you run on a non-standard port (e.g. `:8080`). Do not include for production sites.
Anatomy of an absolute og:image URL
text
https://example.com/images/og-cover.jpg
│       │           │
│       │           └── path to the image file
│       └────────────── hostname (your domain)
└────────────────────── scheme (always https://)

HTTPS vs HTTP

Always use `https://` for your og:image URL. If your og:image points to an HTTP URL but your page is served over HTTPS, browsers and some crawlers will block the mixed-content request. Facebook, LinkedIn, and WhatsApp all fetch images over HTTPS and will silently fail or show no image if your URL uses HTTP.

Tip

If your images are hosted on a CDN (Cloudflare, Cloudfront, Fastly, Vercel, etc.), the CDN's HTTPS endpoint is usually the correct absolute URL. Never reference `localhost` or `127.0.0.1` — crawlers cannot reach your local machine.

How to generate the correct absolute URL in different frameworks

The most common source of relative-URL bugs is that developers build og:image values using string concatenation without explicitly including the origin. Here is the correct pattern for the most popular frameworks and environments.

1

Next.js (App Router)

In Next.js 13+ with the App Router, use the `metadataBase` property in your root layout. This tells Next.js what origin to use when resolving relative image paths in `openGraph.images`.

app/layout.tsx
tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  metadataBase: new URL('https://example.com'),  // ← sets the base
  openGraph: {
    images: ['/images/og-cover.jpg'],  // Next.js resolves to absolute URL
  },
};

Without `metadataBase`, Next.js will emit a relative path in the HTML output, and social crawlers will fail to load the image. This is one of the most frequently missed configurations in Next.js deployments.

2

Next.js (Pages Router)

In the Pages Router with `next/head`, you must construct the full absolute URL manually, typically using an environment variable for the site origin.

pages/blog/[slug].tsx
tsx
const SITE_URL = process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com';

<Head>
  <meta
    property="og:image"
    content={`${SITE_URL}/images/og-cover.jpg`}
  />
</Head>
3

Plain HTML / static sites

There is no framework magic here — just write the full URL directly. The only variable to manage is ensuring you use the production domain, not localhost.

index.html
html
<meta property="og:image" content="https://example.com/images/og-cover.jpg" />
4

WordPress

Plugins like Yoast SEO, Rank Math, and All in One SEO automatically generate absolute og:image URLs by combining `home_url()` with the uploaded image path. If you are setting og:image manually in a theme, use `get_site_url()` to construct the absolute URL rather than hardcoding the domain.

functions.php (manual approach)
php
$og_image = get_site_url() . '/wp-content/uploads/og-cover.jpg';
echo '<meta property="og:image" content="' . esc_attr($og_image) . '" />';
5

Environment-variable approach (recommended for any stack)

Hardcoding your domain in code is fragile — staging and production environments use different domains, and a typo means broken previews everywhere. The cleanest pattern is to store your site's base URL in an environment variable and reference it when building og:image values.

.env.production
bash
NEXT_PUBLIC_SITE_URL=https://example.com
lib/seo.ts
ts
export const SITE_URL =
  process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com';

export function absoluteOgImage(path: string): string {
  // Ensure path starts with /
  const normalized = path.startsWith('/') ? path : `/${path}`;
  return `${SITE_URL}${normalized}`;
}

// Usage:
// absoluteOgImage('/images/og-cover.jpg')
// → 'https://example.com/images/og-cover.jpg'

Open Graph Preview Text Optimizer

Check your og:title and og:description length, truncation risk, and social-preview copy quality — instantly in your browser.

Open tool

WhatsApp-specific requirements for og:image

WhatsApp link previews are generated by its own crawler, which has stricter requirements than Facebook or LinkedIn in several areas. If your og:image works on Facebook but not on WhatsApp, one of these constraints is usually the cause.

  • Absolute HTTPS URL — same as every other platform; WhatsApp does not follow redirects from HTTP to HTTPS.
  • Image must be publicly accessible — no authentication, no bot protection that blocks the WhatsApp crawler IP ranges.
  • Minimum image size: 300×200 px — images smaller than this are often ignored by the WhatsApp link preview renderer.
  • Maximum file size: ~300 KB — WhatsApp's crawler has a short timeout for image fetches. Large images either timeout or get skipped.
  • JPEG or PNG format — WebP support varies by WhatsApp version and platform. Stick to JPEG for maximum compatibility.
  • og:image:width and og:image:height are strongly recommended — they allow WhatsApp to size the preview container before fetching.

Warning

WhatsApp aggressively caches link previews. If you fix a broken og:image, users who have already shared the link may still see the old (broken) preview until WhatsApp's cache expires — typically 24–72 hours. Facebook and LinkedIn both have debugger tools you can use to force-refresh the cache; WhatsApp does not expose one publicly.
Optimal og:image block for WhatsApp compatibility
html
<!-- Core og:image — must be absolute HTTPS URL -->
<meta property="og:image" content="https://example.com/og/article-cover.jpg" />

<!-- Strongly recommended companions --&gt;
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:alt" content="Article title or brief description" />

<!-- Required for WhatsApp to show a full link card (not just a URL) --&gt;
<meta property="og:title" content="Your Page Title Here" />
<meta property="og:description" content="Brief description of the page content." />
<meta property="og:url" content="https://example.com/your-page" />

Meta Tag Generator

Generate a complete Open Graph, Twitter Card, and standard meta tag block in seconds — with real-time preview and SEO audit warnings.

Open tool

Common mistakes and how to fix them

Even experienced developers make the same og:image mistakes repeatedly. Here are the most frequent issues and their exact fixes.

Mistake 1: Using a relative path

❌ Wrong — relative path
html
<meta property="og:image" content="/images/og-cover.jpg" />
✓ Correct — absolute URL
html
<meta property="og:image" content="https://example.com/images/og-cover.jpg" />

Mistake 2: Using localhost in production builds

This typically happens when a staging or local-dev environment variable gets committed without being overridden for production.

❌ Wrong — localhost is unreachable by crawlers
html
<meta property="og:image" content="http://localhost:3000/og.jpg" />

Mistake 3: Missing og:image entirely

If no og:image is present, platforms will attempt to find an image in the page content — usually with poor results. Always provide an explicit og:image on every page you expect to be shared. You can use Aback's Meta Tags Analyzer to instantly audit any live URL and confirm whether og:image is present and correctly formatted.

Mistake 4: Image returns a 4xx or 5xx status

An absolute URL that is correct in form but broken in practice — 404, 403, 500 — will produce the same result as no image: a blank preview. Always verify that the image URL returns a 200 OK with the correct `Content-Type` header.

Mistake 5: Image is behind authentication

Social crawlers do not send cookies or auth headers. If your og:image URL requires a login, or is on a staging server protected by HTTP basic auth, the crawler will get a 401 or a login-page HTML response instead of the image. og:image files must always be publicly accessible, even when the page itself is behind a paywall.

Mistake 6: Wrong image dimensions

Images that are too small (under 200×200 px) may be ignored. Images with unusual aspect ratios may render with cropping or letterboxing. The universal safe dimensions are 1200×630 px at a 1.91:1 ratio. You can generate a correctly-sized og:image in seconds with the OG Image Generator.

IssueSymptomFix
Relative pathNo image shown on sharePrefix with https://yourdomain.com
localhost URLNo image shown on shareUse production domain; check env vars
HTTP (not HTTPS)No image or mixed-content errorServe image over HTTPS
Image 404/403No image shown on shareFix image path or access permissions
Auth-protected imageNo image shown on shareMove image to public CDN path
Wrong dimensionsCropped or missing previewUse 1200×630 px JPEG or PNG
No og:image:width/heightSlow or missing preview on WhatsAppAdd og:image:width + og:image:height

How to verify your og:image is correct

Setting the tag correctly in code is one thing — confirming it actually works is another. Here are the fastest ways to verify.

1

Use the Meta Tags Analyzer

The Meta Tags Analyzer on Quasar Tools lets you enter any live URL and see every meta tag the page emits, including og:image. It checks whether the value is present, whether the URL is absolute, and flags common format issues. This is the fastest first-pass check.

2

Use Facebook's Sharing Debugger

Facebook's Sharing Debugger (`developers.facebook.com/tools/debug`) fetches and renders the Open Graph data for any URL, shows you exactly what image will appear, and lets you force-scrape to clear the cache. It is the authoritative source for Facebook and Instagram previews.

3

Use LinkedIn's Post Inspector

LinkedIn's Post Inspector (`linkedin.com/post-inspector`) performs the same function for LinkedIn previews. It is particularly useful because LinkedIn's crawler behavior differs from Facebook's in how it handles cache and HTTPS redirects.

4

Inspect the HTML source directly

View the page source (`Ctrl+U` / `Cmd+U`) or use browser DevTools to read the raw HTML. Find the `og:image` meta tag and copy the value. If it does not begin with `https://`, it will fail for any crawler.

5

Test the image URL independently

Paste the og:image URL directly into a browser tab. If you get a 404, a login page, or anything other than the image, crawlers will get the same response. The URL must return the raw image with a 200 OK.

Meta Tags Analyzer

Audit any live URL for og:image presence, absolute URL format, Twitter Card tags, and 15+ other SEO signals in one scan.

Open tool

og:image across different platforms

Different platforms handle og:image slightly differently. Understanding these differences helps you write a single meta tag that works everywhere.

PlatformMin sizeRecommended sizeFormatCaching
Facebook / Instagram200×200 px1200×630 pxJPG, PNG, GIFPersistent; use Debugger to clear
LinkedIn200×200 px1200×627 pxJPG, PNGPersistent; use Post Inspector
WhatsApp300×200 px1200×630 pxJPG, PNGPer-device; hard to clear
Telegram200×200 px1200×630 pxJPG, PNG, WebPLong-lived; regenerates on reshare
Discord256×256 px1200×630 pxJPG, PNG, GIFShort-lived; auto-refreshes
Slack500×500 px1200×630 pxJPG, PNGPer-workspace; clears after ~30 days
X (Twitter)144×144 px1200×600 pxJPG, PNG, WebP~7 days; use Card Validator to clear

Note

X (Twitter) uses its own `twitter:image` meta tag alongside og:image. When `twitter:image` is absent, X falls back to `og:image`. For maximum Twitter control, set both tags — and set `twitter:card` to `summary_large_image` to get a full-width preview instead of a small thumbnail. The [Meta Tag Generator](/tools/web/utilities/meta-tag-generator) generates both sets of tags simultaneously.

Dynamic og:images

A growing pattern is to generate og:images dynamically per page — for example, a blog post's og:image might include the article title and author name, generated server-side as a PNG. Frameworks like Next.js support this with the `ImageResponse` API (`next/og`). The output is still an absolute URL — the dynamic generation happens on the server; the crawlers just see a normal `https://` image URL.

If you prefer a no-code approach, the OG Image Generator lets you design a custom 1200×630 px social preview image with your own text, colors, and layout, then download it as a PNG — ready to upload to your CDN and reference as an absolute URL.

og:image alongside the full Open Graph tag set

og:image rarely works in isolation. Platforms use the full set of Open Graph tags together to decide whether to render a rich link card or just a plain URL. If you are adding og:image to a page, these are the other tags you should include at the same time:

  • og:title — the headline of the link card (typically matches `&lt;title&gt;` but can be shorter)
  • og:description — a 1–2 sentence summary that appears below the title; check length with the OG Preview Text Optimizer
  • og:url — the canonical URL of the page (use the same URL as your `&lt;link rel="canonical"&gt;`)
  • og:type — `website` for most pages; `article` for blog posts
  • og:site_name — your website or brand name
  • og:image — the absolute URL of your preview image (the focus of this article)
  • og:image:width and og:image:height — strongly recommended for faster rendering
  • og:image:alt — descriptive alt text for accessibility and AI-readable context
Complete Open Graph block
html
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Your Site Name" />
<meta property="og:title" content="Your Article Title" />
<meta property="og:description" content="A brief, compelling description under 155 characters." />
<meta property="og:url" content="https://example.com/blog/your-article" />
<meta property="og:image" content="https://example.com/og/your-article.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:alt" content="Visual description of the preview image" />

<!-- Twitter / X fallback --&gt;
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://example.com/og/your-article.jpg" />

You can generate and validate this entire block — including og:image with an absolute URL check — using the Meta Tag Generator or validate an existing page with the Meta Tags Analyzer.

Key takeaways

  • og:image must be an absolute URL — relative paths, protocol-relative URLs, and data URIs will all fail silently.
  • Always use https:// — HTTP images are blocked by mixed-content rules and many crawlers refuse them.
  • The recommended og:image size is 1200×630 px (1.91:1 ratio) at under ~300 KB for JPEG.
  • Include og:image:width and og:image:height to speed up preview rendering on WhatsApp and Telegram.
  • In Next.js App Router, set metadataBase to avoid relative-path output; in Pages Router, build the full URL with an environment variable.
  • Verify with the Meta Tags Analyzer, Facebook Sharing Debugger, and LinkedIn Post Inspector before publishing.
  • Crawlers cannot reach localhost, staging servers behind auth, or images returning 4xx/5xx — og:image files must be publicly accessible.

Frequently Asked Questions

Social platform crawlers are independent HTTP clients that visit your page URL to read its meta tags. When they encounter a relative path like /images/og.jpg, they have no base URL to resolve it against — they only know the page URL they fetched, not your site's origin. An absolute URL like https://example.com/images/og.jpg is self-contained and can be fetched by any client from any context without additional resolution. This is why the Open Graph protocol specification requires absolute URLs.

The universally recommended og:image size is 1200×630 pixels at a 1.91:1 aspect ratio. This renders correctly on Facebook, LinkedIn, X (Twitter), WhatsApp, Discord, Slack, and Telegram. Minimum viable size is around 300×200 px for WhatsApp and 200×200 px for Facebook, but images below 600×315 px will appear as small thumbnails rather than large preview cards. Keep file size under 300 KB (JPEG quality ~85) for fast loading by crawlers.

No. Protocol-relative URLs (//example.com/og.jpg) are missing the scheme component and are not supported by Facebook's, LinkedIn's, or WhatsApp's crawlers. Always use the full https:// prefix. Protocol-relative URLs were a historical browser pattern for handling HTTP vs HTTPS automatically, but they are not valid in the context of og:image.

In the App Router, set metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL ?? 'https://example.com') in your root layout.tsx. Next.js will then automatically resolve relative image paths in openGraph.images to absolute URLs using that base. In the Pages Router, build the absolute URL manually using a NEXT_PUBLIC_SITE_URL environment variable and string concatenation, then pass the full URL to the og:image meta tag.

WhatsApp has several extra constraints: the image must be under ~300 KB, must be JPEG or PNG (WebP is inconsistent), must be served over HTTPS, and the server must respond quickly. WhatsApp also aggressively caches link previews, so if you shared the URL before fixing the og:image, some users will see the old (broken) preview for 24–72 hours. Additionally, WhatsApp requires og:title and og:description to be present alongside og:image to render a full link card.

Yes, and it is the recommended approach. A CDN URL (e.g. https://cdn.example.com/og-cover.jpg or a Cloudflare/Vercel/CloudFront URL) is a perfectly valid absolute URL and will typically load faster for crawlers than an origin server. Just make sure the CDN path is public (no authentication), the image is served with the correct Content-Type header, and the URL does not redirect from HTTP to HTTPS (use the HTTPS URL directly).

Use both. og:image is the standard that Facebook, LinkedIn, WhatsApp, Discord, Telegram, and Slack all read. twitter:image is the X (Twitter) equivalent. When twitter:image is absent, X falls back to og:image — so you can omit twitter:image and X will still show a preview. But setting twitter:image explicitly gives you more control over the X-specific preview, and pairing it with twitter:card="summary_large_image" ensures the image renders at full width rather than as a small thumbnail.

ShareXLinkedIn

Related articles