Link previews in Slack and other chat apps

Chat apps build previews from the same Open Graph tags social networks use, so a correct setup works everywhere without per-app effort. Where they differ is layout, caching behaviour, and how they handle links that need authentication — and Slack is notable for being the one that actually honours ordinary HTTP cache headers on your page.

Worth knowing because chat is where a lot of links are actually shared, and it gets less attention than the social platforms.

Same tags, different priorities

A chat preview is typically narrower and shorter than a social card. Practical consequences:

The image is smaller or absent. Many chat layouts show a small thumbnail rather than a full-width image, or unfurl to a compact block with no image at all. Whatever your preview image says needs to survive being 80 pixels wide, or not shown.

The title does more work. With less image, the text carries the card. Another argument for front-loading.

The description is shorter. Chat unfurls often show one line. Say the important thing first.

Your domain is prominent. Chat clients tend to show the host clearly, which is another reason not to spend og:title on your site name.

Design implication: a card that works in a narrow chat unfurl works everywhere. It’s the tighter constraint, so test there.

Slack and cache headers

Slack is the platform most responsive to normal web caching. It re-fetches on its own schedule and honours cache directives on the page, which means:

A wrong preview often fixes itself, in a way it won’t on platforms with long opaque caches.

Sensible cache headers give you control. A short max-age on HTML you expect to change means Slack sees updates sooner.

That’s unusual and useful. If a preview is wrong on Slack specifically, check your page’s Cache-Control header before assuming anything more exotic.

Private and authenticated links

Common frustration: sharing an internal link in a team chat and getting no preview.

Usually correct behaviour. The unfurl is fetched by the app’s servers, not by the reader’s authenticated session, so a page requiring login returns a login page or a 401 — and there’s nothing to build a card from.

Options:

Accept it. For genuinely private content, no preview is the right outcome. A card built from an authenticated page would leak its contents to anyone in the channel, including people without access.

Provide a public metadata page. Some tools expose a minimal public page with a title and no sensitive content, purely so links unfurl usefully.

Use the platform’s own integration. Most chat apps let an authenticated application provide unfurl content for its own domains, which is how internal tools get rich previews. Real work, and the only correct way to preview private content.

What not to do: serve different content to the unfurl crawler than to users. It leaks the content to anyone who can read the channel, and it means the card describes something the reader may not be able to open.

Messaging apps

Phone messaging apps — iMessage, WhatsApp, Signal and similar — also read Open Graph, with two differences worth noting.

Some fetch from the sender’s device, not a central server. That affects privacy (your device contacts the site) and caching (there may be no shared cache, so each sender fetches fresh). It also means a link shared in one of these apps can produce a preview even when a server-side crawler would have been blocked.

Layouts are compact and image-forward. Often a thumbnail and one line of text.

Nothing to do differently. Correct Open Graph plus an image that reads at thumbnail size covers it.

Redirects and shorteners

Chat apps follow redirects to find tags, but the details vary, and shortened links add a hop.

Two things help:

Keep chains short. One redirect is fine. Three, or a chain crossing hosts, is where previews get unpredictable.

Make sure the destination’s og:url is its own canonical address. Some clients display or key caching from it, and a mismatch produces cards attributed to the wrong page.

If a shortened link previews badly while the destination previews correctly, the shortener is the variable — not your tags.

Testing

No neat debug tool for most chat apps, so the practical approach:

Send it to yourself. A direct message to your own account, or a private channel. Immediate and accurate.

Test the narrow layout deliberately. It’s the tightest constraint, so a card that reads well there reads well anywhere.

Check with a fresh URL if you’re iterating, so you’re not fighting a cache while trying to evaluate a design.

The general principle holds: get Open Graph right once, in server-rendered HTML, with an absolute image URL and a title that survives truncation. Chat apps then need no separate work — they’re reading the same tags, just showing them in less space.