Why Large og:image Files Break Social Previews

A preview image can be technically correct and still be a bad preview image.

That is the part teams often miss. The page loads in Chrome. The image looks great in the CMS. The og:image tag is present. Then someone drops the URL into Slack or LinkedIn and the card arrives without an image, with a cropped mess, or with the old asset that was supposed to be gone.

Large Open Graph images are one of the quiet reasons this happens. Not because social platforms hate nice images, but because preview crawlers work under tighter conditions than a human with a browser.

The Short Version

If your preview image is huge, slow, redirected, or generated on demand, a crawler may decide it is not worth using. The fix is usually straightforward: make a dedicated 1200 x 630 sharing image, compress it, serve it from a stable public URL, and test the final page after publish.

For most marketing and product pages, a preview image under 1 MB is a good working rule. Under 400 KB is even nicer when the image still looks clean.

What "Too Large" Means in Practice

Too large is not only pixel size. It can mean:

• a 5000px hero photo used directly as og:image
• a PNG that should have been a JPEG
• a generated image endpoint that takes too long on a cold start
• a CDN path that redirects several times before the real file
• an image that is public in the browser but blocked for crawlers
• a beautiful asset that falls apart when cropped into a small card

The preview crawler does not care that the page eventually settles into a nice layout. It is trying to build a card quickly from metadata, image URLs, response headers, and cache state.

Slack documents that its link-expanding robot fetches metadata tags and then fetches referenced media files to check validity. That means the image is not a decorative afterthought. It is part of the crawl.

Why Browsers Hide the Problem

Browsers are patient compared with preview crawlers.

A browser can load a large image after the rest of the page. It can retry. It can use cookies. It can benefit from a user's local cache. It can run JavaScript and wait for your image component to hydrate.

Preview crawlers are more direct:

1. Fetch the URL.
2. Read the initial HTML.
3. Extract metadata.
4. Fetch the image.
5. Build or cache the card.

If the image is slow, blocked, or awkwardly delivered, the platform may build a text-only card or keep showing an older preview.

That is why "works on my machine" is a weak test for social previews. Your machine is not Slackbot, LinkedIn, or X.

Fix the Asset, Not Just the Tag

The tag can be correct while the asset is still wrong.

Use this baseline:

• Export a dedicated 1200 x 630 image.
• Keep the subject and any words near the center.
• Use JPEG for photos and complex gradients.
• Use PNG only when transparency or crisp interface detail really matters.
• Compress the file until it is small enough to fetch quickly.
• Serve it from an absolute HTTPS URL.
• Avoid short-lived signed URLs.
• Avoid image URLs that require cookies or logged-in state.
• Declare og:image:width, og:image:height, og:image:type, and og:image:alt.

If the page hero is 3000px wide, keep it as the hero. Just do not make every preview crawler download it to build a small card.

Check the Image URL Directly

When the card image disappears, do not stare at the blog post first. Open the image URL itself.

You are looking for boring answers:

• Does it return 200?
• Is the final URL still the URL in og:image?
• Does it work in a private window?
• Does it return an image content type?
• Is the file size reasonable?
• Does the CDN serve it without requiring a special request header?
• Does the same URL still show an older cached file?

If the image URL fails, the page metadata cannot save it. Fix the asset path, CDN rule, image transformation, or CMS publish step first.

Watch Out for Dynamic Image Generation

Dynamic Open Graph images are useful. They also introduce another place for previews to break.

The risky versions look like this:

• the first request generates the image from scratch
• the generator depends on an API call
• the route has cold starts
• the font file is remote and slow
• the image is generated differently for each query string
• the response lacks stable cache headers

None of those are automatically wrong. They just deserve a production check. If a campaign depends on the card, warm the image route or store the generated asset before launch.

Cache Problems Look Like Size Problems

Sometimes the large file was fixed, but the platform still shows the old card.

That can happen when the page, image, or platform preview is cached. Slack says responses to its link-expanding robot are cached globally for around 30 minutes. LinkedIn tells publishers to use Post Inspector when an old cached image appears, and notes that refreshed metadata affects new posts, not posts that already exist.

So before you edit the image again, separate two states:

If the source is clean, use the right refresh tool or wait for the cache window. If the source is not clean, cache-busting only creates a second mess.

A Release Checklist for Preview Images

Before you share an important URL, run this:

1. Inspect the final public URL, not a preview URL.
2. Confirm og:image is present in the raw HTML.
3. Open the image URL directly.
4. Check dimensions and file weight.
5. Confirm width, height, type, and alt metadata.
6. Scan the page with the link preview checker.
7. Test platform-specific behavior for Slack, LinkedIn, or X when the link is important.
8. If the card is stale, follow the Open Graph image refresh checklist.

For recurring CMS or product updates, fold this into release QA. Broken preview images are easy to miss in a visual review because the page itself can still look completely fine.

Make the Preview Asset Boring

This is one of those engineering problems where boring is a compliment.

A good og:image has a stable URL, loads quickly, has a predictable shape, and does not depend on the viewer's session. It is not trying to be the biggest or highest-resolution file in the CMS. It is trying to be fetched reliably by crawlers that have very little context and not much patience.

When in doubt, make a smaller dedicated asset and test the final URL. That fixes more preview bugs than another round of title edits ever will.