Link Previews with Images and Titles: Checking Open Graph Metadata

A shared link can become a preview with an image, title and description. The receiving platform chooses the layout and data sources. Open Graph tags are entries in the page’s HTML source that specify information such as its title and image. These tags help describe a page; the tags do not guarantee a particular card on every service.

A saved measurement from 5 September 2026 covers eighteen URLs. The findings below describe the responses received by that checker at that time, not current screenshots from eighteen social platforms.

Metadata and platform rules are different layers

The Open Graph protocol requires og:title, og:type, og:image and og:url. The recommended og:description adds a short description. The URL identifies the object, while the type distinguishes, for example, a website from an article.

Platforms may also use twitter: tags, oEmbed or other information. Slack explicitly documents several such sources. There is no universal rule that a missing Open Graph title always becomes the HTML title or that a missing Open Graph image always produces a text-only card. Explicit, consistent metadata reduces reliance on platform-specific choices.

What the historical responses contained

Five of the eighteen responses contained no detected Open Graph tags; thirteen included an image. The saved findings also record two non-success responses and a redirected response among those five. Missing tags in such a response do not establish what a permitted crawler or a normal browser would receive. The dataset does not contain complete response bodies, so assertions about unreadable page content cannot be verified from this record.

Nine responses had no twitter:card. Two wide images were paired with summary; a third summary declaration accompanied a square image. These are observed declarations, not proof of the final card size or of an accidental design choice.

Eight image sizes, no universal crop

The thirteen downloaded images used eight dimension pairs:

• 1200 × 630: six images.
• 2400 × 1350, 1300 × 731, 1280 × 686 and 1024 × 576: one each.
• 585 × 368, 500 × 500 and 1024 × 1024: one each.

The ratio of 1200 × 630 is approximately 1.90:1. That is a useful wide format, not an Open Graph requirement. LinkedIn recommends 1.91:1 for customized Page-post previews, while its guidance also describes mobile display without cropping. The claim that every service crops every image to the same frame is therefore too broad. Neither 585 × 368 nor 500 × 500 proves that a service must switch to a small card.

Important content benefits from room around the edges, with the result checked on the intended platform. A local schematic preview cannot certify that crop.

Dimensions and image descriptions

Eight of the thirteen image responses lacked declared width or height. One saved checker finding flags a mismatch between declared and downloaded dimensions on the Wikipedia HTTP page. The summary does not preserve the original declared numbers.

og:image:width and og:image:height should describe the actual file. These optional fields can help consumers interpret an image; omission alone does not prove a timeout or explain a missing picture. Image access, response time, file type and the receiving service also matter.

Only two image entries contained og:image:alt, on MDN and BBC News. The protocol recommends an image description rather than a caption. Whether a service exposes that text to assistive technology depends on its implementation; titles and descriptions can also convey accessible information.

The historical finding on this blog

The recorded German blog index had a title, a 1200 × 630 image and summary_large_image, but no og:description. The checker recorded an available meta description. That supports a possible fallback in the checker, not proof that every platform displayed the correct wording. It is a dated finding, not a claim about the current index.

A reproducible first check

The following Bash example requires curl 8.4 or later and Python 3. It fetches one HTTPS page with limits, then lists Open Graph and Twitter metadata from an explicit HTML head. The parser handles multiline tags and several tags on one line. The example assumes UTF-8, does not run JavaScript and does not fetch images or reproduce a platform crawler.

set -eu
sample=$(mktemp)
trap 'rm -f "$sample"' EXIT
curl --fail --silent --show-error --location --max-redirs 5 \
  --connect-timeout 5 --max-time 20 --max-filesize 2097152 \
  --proto '=https' --proto-redir '=https' \
  --output "$sample" 'https://example.com/'
python3 - "$sample" <<'PY'
from html.parser import HTMLParser
from pathlib import Path
import sys

class HeadMeta(HTMLParser):
    def __init__(self):
        super().__init__()
        self.in_head = False

    def handle_starttag(self, tag, attrs):
        if tag == 'head':
            self.in_head = True
        if tag == 'meta' and self.in_head:
            fields = dict(attrs)
            name = (fields.get('property') or fields.get('name') or '').lower()
            if name.startswith(('og:', 'twitter:')):
                print(name, '=', fields.get('content', ''))

    def handle_endtag(self, tag):
        if tag == 'head':
            self.in_head = False

parser = HeadMeta()
parser.feed(Path(sys.argv[1]).read_text(encoding='utf-8', errors='replace'))
parser.close()
PY

The Open Graph and Social Card Checker also measures a downloaded image and supplies a local preview. Its fallback order and size warnings are checker rules, not a guarantee of a platform result. The embedded image preview avoids a direct image request from the visitor’s browser; the checker’s server still requests the page and image from the destination servers, which can observe those requests.