A page declares <meta property="og:image" content="/images/card.png"> and the link preview shows no image on any platform. What is wrong, and which companion og:image properties are worth adding?
answer
- scraper has no base URL to resolve against
- URL-typed properties are absolute by specification
- declare the box before the bytes arrive
- alt text for the card, not the page
- anonymous fetch must return 200
basics
~20 sOpen Graph requires absolute URLs, so a root-relative path is unusable by the scraper. Use the full https:// URL, and add og:image:width, og:image:height, og:image:type and og:image:alt so platforms can lay the card out before the file downloads.
solid answer
~40 sOpen Graph URL-typed properties must be absolute — the protocol has no notion of resolving against the page — so `/images/card.png` gives the scraper nothing it can fetch, and the card renders without art. The fix is `content="https://example.com/images/card.png"`, ideally over HTTPS since most platforms will not load mixed content into a card. Alongside it, `og:image:width` and `og:image:height` let a platform reserve the right box before it has downloaded the file, `og:image:type` states the MIME type, and `og:image:alt` supplies alternative text for the card image on the consuming platform. The image itself also has to be publicly reachable — no auth wall, no bot blocking, a real 200 response — and sized for the layout you want: around 1200×630 (roughly 1.91:1) is the widely used shape for a large card.
code
html · 7 lines<meta property="og:url" content="https://example.com/blog/checkout-latency">
<meta property="og:title" content="How we cut checkout latency in half">
<meta property="og:image" content="https://example.com/cards/checkout.png">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Line chart of checkout latency dropping by half">go deeper
Remember the one hard rule: Open Graph image and URL values must be absolute, with scheme and host, even though a plain img tag on the same page can use a relative path.
Explain what each og:image sub-property buys you — dimensions for layout before download, type for the consumer, alt for card accessibility — and when secure_url is redundant.
An interviewer expects the reachability angle: staging auth gates, WAF bot rules and CDN geo blocking break cards for everyone but the author, and you should be able to prove it with an anonymous fetch.
Own the pipeline decision — whether card images are hand-designed assets, build-time renders, or generated per URL — and what each choice costs in cache invalidation and review burden.
## Why the relative URL fails Open Graph properties whose type is URL — `og:image`, `og:url`, `og:video`, `og:audio` — are specified as absolute URLs. The protocol was designed for values that get stored and re-served by a platform, far away from the page they came from, so there is no base against which a relative reference could be resolved. A scraper that reads `/images/card.png` has a string it cannot turn into a request, and the card falls back to no image or to a guessed one. ```html <!-- unusable: no scheme, no host --> <meta property="og:image" content="/images/card.png"> <!-- correct --> <meta property="og:image" content="https://example.com/images/card.png"> ``` This is one of the few places in HTML authoring where a relative URL is simply wrong rather than merely unusual, which is why it catches people out: `<img src="/images/card.png">` on the same page works fine. ## The companion properties Open Graph defines structured sub-properties for images, each written as its own `<meta>` tag immediately after the `og:image` it belongs to: ```html <meta property="og:image" content="https://example.com/cards/post-42.png"> <meta property="og:image:type" content="image/png"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta property="og:image:alt" content="Line chart of checkout latency dropping by half"> ``` - **`og:image:width` / `og:image:height`** are the useful ones operationally. A platform that knows the dimensions up front can reserve the correct box and decide the card layout without waiting for the bytes; without them, some consumers render a smaller fallback card on the first share and only upgrade after they have fetched and measured the file. - **`og:image:type`** is the MIME type (`image/png`, `image/jpeg`, `image/webp`). Cheap to emit, and it saves a consumer from sniffing. - **`og:image:alt`** is alternative text for the card image as shown on the consuming platform. It is not the page's own `alt`; it describes the card art to someone reading the post in a screen reader. Write what the image conveys, and do not restate `og:title` — the title is already read out. - **`og:image:secure_url`** exists for the historical case of an HTTP page pointing at an HTTPS copy of the image. On an all-HTTPS site it is redundant; put the `https://` URL in `og:image` itself. Order matters: the sub-properties attach to the most recent `og:image`, so if you emit two images, keep each one's `:width`/`:height` grouped with it. ## Reachability, not just spelling An absolute URL is necessary but not sufficient. The scraper is an anonymous client from an unfamiliar network: - The image must return **200** with an image content type. A redirect chain usually survives; a 403 does not. - It must not sit behind **authentication**, a staging Basic-Auth gate, or a paywall — a very common reason previews work locally for the author and nowhere else. - It must not be blocked by **bot filtering or geo rules** at the CDN. Preview scrapers announce themselves with their own user agents, and an over-eager WAF rule that blocks unknown agents silently kills every card. - It should be **HTTPS**. Platforms serving cards over HTTPS will not pull an `http://` image into them. ## Sizing The protocol does not mandate dimensions, but each consuming platform publishes its own constraints, typically a minimum size, a maximum file size (X documents a 5 MB ceiling for card images) and a preferred aspect ratio. The de-facto convention for a large horizontal card is **1200×630**, about 1.91:1, which is why so many design templates ship at that size; square cards are used for the small summary layout. Two practical consequences: text baked into a card image should be large, because the card is often rendered a few hundred pixels wide, and anything near the edges can be cropped when a platform re-frames the image to its own ratio, so keep the important content centred. ## Debugging the empty card When an image does not appear, check in this order: is the URL absolute and HTTPS; does it return 200 to an anonymous `curl` from outside your network; is the content type an image; are width and height declared and honest; and does the file fall inside the platform's size and ratio limits. Only after all five should you suspect a caching problem on the platform side.
- Why does declaring og:image:width and og:image:height change anything if the platform is going to download the file anyway?Because the card often has to render before the fetch completes, or on a first share where the image has not been scraped yet. Declared dimensions let the platform pick the right layout — large horizontal card versus small thumbnail — and reserve the box immediately. Without them some consumers render the fallback layout on the first share and only upgrade after a later re-scrape.
- How is og:image:alt different from the alt attribute on the same image on the page?They serve different surfaces. The `alt` attribute describes the image inside your document, to a user reading your page. `og:image:alt` describes the card art inside someone else's feed, where your page's markup does not exist. The text is often similar but the context differs, and `og:image:alt` should not simply repeat `og:title`, which the platform already exposes.
- A card image works when you open its URL in your browser but never appears in previews. Where do you look?At what an anonymous, unfamiliar client sees. Fetch the URL with `curl` from outside your corporate network and without cookies: you are looking for an auth gate, a Basic-Auth staging password, a 403 from bot filtering or a WAF rule that rejects unknown user agents, or a geo restriction. Your browser has a session; the scraper has nothing.
saying these in an interview costs you the question
- Uses a root-relative path in og:image
- Thinks the scraper resolves the URL against og:url
- Puts og:image:alt in as a duplicate of og:title
- Ignores that the image must be publicly fetchable without auth
- Assumes any aspect ratio renders the same on every platform