Your og:image is probably the wrong shape

It depends on one other tag, which is the part people miss. twitter:card chooses which of two layouts a platform uses:

• summary_large_image — the big banner card. It renders at roughly 1.91:1, and 1200 × 630 is the conventional size to supply.
• summary — the small card with a thumbnail beside the text. Roughly square.

Declaring one and supplying an image shaped for the other is the whole bug. And because the platform fits rather than rejects, both mistakes look completely fine on your end. The tag is there. The image resolves. Your validator is happy. Somewhere else, a person sees the middle third of your wordmark.

Worth saying plainly, since these tags have a reputation for being fiddly: the ratio is what matters, not the exact pixel count. A 2400 × 1260 image is the same shape as a 1200 × 630 one and previews identically.

We read the number out of the PNG’s own IHDR header rather than trusting the filename or the CSS, and by two independent routes — once off the file on disk, once by fetching the first 16 KB of the live URL. Both gave the same answer.

At 2.3× too wide, more than half the width of the image is cut. What survives is a centre slice of a wordmark with the first and last letters gone — which is worse than no image at all in one specific way: it looks like a rendering bug on the platform, not a choice.

This is the part we had not seen written down anywhere, so we measured it. One unauthenticated GET per homepage, the Open Graph tags read out of the served HTML, then a Range: bytes=0-16383 request against each image so we could read its real dimensions out of the file’s own header without downloading the whole thing. Measured 12 August 2026.

Reading it honestly, four things stand out:

• One site got it exactly right. Poki declares the wide card, serves 1200 × 630, and declares dimensions that match the file. That is the whole specification, done.
• Y8 has our bug, smaller. It declares the wide card and serves a square 500 × 500 logo. Same class of mismatch as ours, at 1.9× instead of 2.3×.
• A declared dimension can drift from the file. CrazyGames’ markup says the image is 630 tall; the file the CDN actually delivered to us is 600. The image URL itself even asks for height=630&fit=crop. Thirty pixels is cosmetically nothing — but it is a live example of a hardcoded number and a real file disagreeing, which is the argument for generating those tags rather than typing them.
• Three of nine ship no og:image on the homepage at all, and itch.io declares summary_large_image while supplying nothing to put in it. A card with a hole in it.

The instinct on finding a broken share image is to build a card and put it on every page. We have 235 pages, so that is 235 edits.

Counting first said otherwise. 212 of the 235 were never part of the defect. Those pages point og:image at the individual game’s own thumbnail rather than at any site-level image. We sampled 25 of the 200 catalogue thumbnails at random by range request, and 25 of 25 came back 1920 × 1080; a full sweep of all 200 resolved 196 at that size and left 4 unresolved.

16:9 is 1.778:1. Into a 1.91:1 card that is a trivial crop — a few per cent off the top and bottom. Those pages were fine.

They were also better than fine. A preview showing the actual game tells a reader what they are about to click; a brand card tells them the domain, which the platform already prints underneath. Putting a generic card on 212 game pages would have been a downgrade dressed up as a fix — the kind you never detect afterwards, because everything you changed still validates.

So 23 pages needed the new card, not 235. The general rule we took from it:

og:image:width and og:image:height let a platform lay out the preview before it has fetched the image. That is a genuine benefit and we do declare them — on the 23 pages using our own card.

We deliberately did not add them to the 212 pages whose images live on someone else’s CDN. Of 200 thumbnails, 4 did not resolve: three whose dimensions were not inside the first 8 KB, and one that timed out. Writing 1920 × 1080 on all 200 would mean publishing a number we had not verified about a remote file that can change without telling us. Leaving the tags off costs nothing, because platforms measure the image once they fetch it.

Our own card’s tags are safe for a different reason: the build reads them out of the PNG header at generation time, so the declared number cannot drift from the asset. Which is exactly the failure mode the CrazyGames row above is a live example of.

The underlying principle is the same one that governs every other number we publish: a dimension you have not measured is a claim, not a fact.

All 17 of our blog posts carried the wide wordmark. That is not a coincidence and it is not carelessness — it is the same structural hole that had just cost us three untagged pages, described in an earlier post about missing analytics tags.

The mechanism, in one sentence: a hand-authored page starts life as a copy of an older page’s <head>, so it inherits whatever that head contained — and the generator deliberately never overwrites a file a human wrote, so the template can never reach in and correct it. Every hand-written page is a snapshot of your head element on the day it was created.

The repair is a build step rather than a checklist item, because a checklist still depends on somebody remembering on file number eighteen. It is deliberately narrow: it only touches a page whose og:image is one of our own logo files. Give a post a real cover image of its own and it is left completely alone.

A missing one. A cropped image looks like a glitch; a preview with no image at all looks like a dead link, and it is the exact failure you invite when you repoint every page at a brand-new file that has not shipped yet.

So the card is protected three separate ways, none of which trusts the others:

1. The build throws a fatal error if the card is missing from source, before it writes anything.
2. The generator copies the card into the output as part of the build rather than relying on someone to remember it.
3. The bundle assembler asserts that every same-host og:image resolves to a real file in the bundle before it can be shipped.

And each of those assertions was proved able to fail — run against a deliberately broken copy of the site to confirm it catches the break, then against the clean one to confirm it still passes. A check that has never failed is not a check; it is a line of code you feel good about.

1. Read your own markup from outside. curl -s https://yoursite.com/ | grep -o 'og:image[^>]*' — and note your twitter:card value in the same pass, because the two only make sense together.
2. Measure the file, not the CSS. Fetch the first 16 KB and read the header. For a PNG that is four bytes at a known offset:

import urllib.request, struct
req = urllib.request.Request(IMG_URL, headers={"Range": "bytes=0-16383"})
b = urllib.request.urlopen(req).read()
w, h = struct.unpack('>II', b[16:24])      # PNG IHDR
print(w, h, round(w / h, 3))

3. Divide. Anything outside roughly 1.7 – 2.1 will visibly crop in a wide card. A wordmark will be somewhere around 4. A square logo will be 1.0.
4. Check the image resolves from outside your network, on a clean request. A 404 here is worse than a bad ratio.
5. If you declare width and height, confirm they match the file. They drift, as the table above shows.
6. Then do your second-most-shared page type, not just the homepage. This is the step that actually pays. Ours was fine on 212 pages and broken on 23 — and the 23 were the ones anybody shares.
7. Control your own probe. Point the same script at a URL you know is not an image and at one you know does not exist. If it returns a confident answer for both, it is not measuring anything.

That last one is not padding. The reason this defect lived on our site for as long as it did is that everything we had ever pointed at it reported success.

• Newgrounds is unmeasured. It returned 403 to our request. That is our access, not their markup, and we are not going to guess a row.
• We measured homepages, once, on one day. Inner pages commonly differ, and a site may serve different markup to a logged-in visitor or a named crawler.
• Whether any of this improves click-through is unknown, and we are not going to claim it. We have no before-baseline for share-card clicks, so the honest status is unmeasured rather than improved.
• The fix is not live on slowden.com yet. It is complete and verified in our deploy bundle, but the machine that built it has no deploy path, so as of publishing this the live site still serves the 4.38:1 wordmark — we re-checked, and the new card returns 404 on live. Saying so is simpler than the alternative, and you can verify it yourself with the curl in step 1.

• Why 3 of our 16 blog posts had no analytics tag — the same structural hole, found a different way.
• The same URL served me two different images — more measuring of images you do not host.
• The star rating your iframe added to your page — metadata attributed to you that you did not write.
• Why your game breaks inside an iframe — another set of defaults nobody chose.
• Why players leave before your game starts — what happens once you can finally measure.
• Why your browser game is unplayable on a phone — an audit of our own catalogue.
• How to actually finish a game in one month — scoping a Slow Cook entry.

SlowDen is a place to put a browser game where people can find it and play it — no download for the player, no store page for you. Games here come from creators, partners and third-party sources, and each one is credited to whoever made it.

Slow Cook is our creative challenge round. You get a prompt, you build something around it, you submit it for consideration. Selected entries have a chance to be featured, and selected winners may receive a shoutout across SlowDen’s social accounts. That is the honest list; there is nothing guaranteed beyond it. Check the Slow Cook page for the current round and its closing date.

Submit a browser gameSee the Slow Cook challenges