We fetched the share image of every tool we list. 153 of them do not produce a card.

The og:image is the picture that appears when someone pastes your link into Slack, X, LinkedIn or a group chat. It is the only part of your site most people will see before deciding whether to click.

It is also the one piece of page metadata nothing generates for you. A framework gives you a title and a favicon by default. Nobody gets a share image by accident.

So we fetched all of them. Every tool in this catalogue, on 9 August 2026: read the page, find the og:image, then actually request the image and measure it.

The funnel

444 of 673, or 66%, hit the size everyone recommends. A further 76 are below it and still render as a large card, so 520 of 673 — 77% — get a proper card. The rest have an image that is missing, broken, unrenderable, or too small to be one.

The four ways it goes wrong

No image at all — 97 sites. This is not a beginner's mistake, which is the part that surprised us. Tabnine has six og: tags on its homepage and no og:image among them — somebody set up Open Graph and stopped one line short. Aider and Replicate serve no og: tags at all. These are well-known products with real teams.

The URL does not load — 14 sites. Eight return a plain 404, three return 403, one a 502. The tag is there, the value looks right, and the file behind it is gone. This is the failure nobody catches, because the page still looks correct in the browser and the tag still validates. Only fetching it finds it.

A format that will not render — 13 sites. Six point at an SVG. Three at AVIF. Two serve application/octet-stream, and two return text/html — the URL gives back a web page where an image should be. Social scrapers overwhelmingly want PNG, JPEG, GIF or WebP; the rest silently produce no card.

Too small to be a card — 26 sites, and this is the one worth acting on. Below roughly 600×315 the platforms stop showing a wide card and fall back to a small thumbnail beside the text.

Eighteen of those 26 are perfectly square — 512×512, 400×400, 256×256, 480×480, down to one at 64×64. That is a logo being used as a share image, and we can show it rather than infer it.

Ten of the eighteen have logo, icon or favicon in the image URL. Eight sit at a standard icon size — 512, 256, 180, 128, 96, 64 — which are the sizes you generate for a favicon set and nothing else. And four point og:image at exactly the same file as the site's own touch icon: Anyword, Dezgo, Hailuo AI and MiniMax Agent all declare a real icon link and then reuse that file as their share image.

It is the most common single mistake in this dataset and the one that costs the most, because a square file forces the small treatment no matter how good the artwork is. It is also the easiest to make: the icon is already there, it is already square, and pointing at it looks like it works.

The other 76 that fall under 1200×630 are fine. Twelve of them sit at 1200×628 or 1200×627 — the 1.91:1 ratio that Facebook's own guidance has recommended for years. They get the large card. Our first cut of this article counted them as failures; see the note at the end.

What to do about it, in about ten minutes

Check the tag exists, then request the URL yourself rather than trusting it. curl -I <your og:image url> — a 200 and an image/png or image/jpeg is what you want. That single step catches the 404s and the wrong content types, which together are 27 of the sites here.

Make it 1200×630, as a PNG or JPEG. Not SVG, however much nicer your logo looks as one.

Use an absolute URL. Relative paths work in a browser and fail in scrapers that do not resolve them against your page.

Look at it small. The card is often rendered a few centimetres wide. If the text on your image is unreadable at that size, it is decoration.

Where we got this wrong ourselves

One of the 97 was not a missing tag at all. Our listing for NotebookLM pointed at notebooklm.google.com, which redirects to a Google sign-in page — so what we read, and what any scraper reads, was "Sign in - Google Accounts". The product's actual marketing page at notebooklm.google has a perfectly good share image.

That was our bad URL, not their missing tag. We found it because this audit made us look at what the pages actually said rather than at a checkbox, and we have fixed the listing. It is the only one of the 97 that turned out to be a login or error page — we checked all of them before writing this.

What we are not claiming

One request per site and per image, from one machine, on one day. A CDN having a bad minute would show up here as a broken image, and a site that blocks automated requests shows up as unreadable rather than as anything about its metadata — that is 28 sites we simply cannot speak for.

Dimensions come from parsing the image header. The 13 files in unsupported formats are counted as such rather than measured, and three more in supported formats had headers we could not parse — they sit in none of the size buckets. Two of the 13 are text/html, which is its own answer.

We corrected this article after publishing it. The first version used a flat cut-off of 1200×630 and called everything below it undersized — 102 sites. That was our threshold being wrong rather than their images: twelve of them are at 1200×628 or 1200×627, the ratio Facebook's own guidance recommends, and they render exactly as intended. Redone against what the platforms actually do, the split is 76 that are under the recommendation and still fine, and 26 that are genuinely too small. The 26, and the 18 squares inside them, are the real finding, and they were buried in the first version.

The reading of each page — finding the og:image — is the same code that runs when you submit a tool. Fetching the image and measuring it is not: our check only asks whether the tag is there. Everything past that line in the table above is this article going further than the product does, which is its own small finding.