How WhatsApp and Telegram build link previews

Someone else fetches your page before the recipient does

When a link is pasted into a chat, the messaging platform fetches the URL with its own crawler to build the card the recipient sees. That fetch is not the recipient's browser. It runs from the platform's infrastructure, from an address in a country you did not choose, with no cookies, no session, no consent state and no JavaScript execution worth relying on.

Almost every confusing preview problem follows from that sentence. If the card shows the wrong image, the wrong title or nothing at all, the question is not what the page looks like to you. It is what the page returned to an anonymous, script-free request from an unfamiliar network. Fetching your own URL with a plain command line client and reading the raw HTML is the first diagnostic, and it usually ends the investigation.

Where a short link fits in the fetch

The crawler follows your redirect and reads the metadata from the destination page, so the tags that matter live on the destination, not on the short link. Long chains of redirects are a risk here because some crawlers stop following after a small number of hops, and a preview that works for one messenger and fails for another is very often a chain length difference.

A short link that produces no preview at all, while the destination pasted directly produces a good one, is the clean signature of a redirect the crawler did not follow. Check the number of hops and the status codes before touching the metadata.

The cache is the reason your fix did not work

Both platforms cache what they fetched, keyed on the URL. Once a card has been built for a given link, correcting the page will not change the card, sometimes for a long time. This is the most common support question about previews and it is almost always misdiagnosed as a broken tag.

The reliable workaround is to change the URL. A new short link is a new cache key and gets a fresh fetch. This is a strong argument for testing previews with a throwaway link before you create the one you intend to publish, because the first paste is the one that sets the cache for a link you may then be stuck with.

Image rules are stricter than the documentation suggests

Use an absolute URL over HTTPS for the preview image, served without authentication and without a redirect. Relative paths fail. Images behind a signed URL fail once the signature expires. Very large files are often skipped entirely because the crawler gives up before downloading them, which produces a card with a title and no picture.

Aspect ratio decides whether you get a large card or a small thumbnail, and the platforms disagree about the threshold. A wide image around a two-to-one ratio is the safest general choice. Put the essential content in the middle, because the crop applied differs between the two apps and between phone and desktop layouts.

Telegram is stricter about instant rendering, WhatsApp about scheme

Telegram builds cards from standard metadata and is generally forgiving, but it will not render a preview for a link posted with certain formatting, and it hides previews entirely in some chat settings that the sender cannot influence. WhatsApp tends to be stricter about HTTPS and about the image being reachable without any redirect at all.

The practical response is to test in both, on a phone, in a real conversation, rather than reasoning from the specification. Both platforms change these behaviours without announcement, and a rule that held last year may not hold now.

Titles are truncated brutally in a chat list

The card in a conversation is narrow, and the same link appears in a chat list preview that is narrower still. A title whose meaning depends on its last four words will lose them. Write titles that make sense from the first thirty characters, and treat the description as optional decoration rather than as a place to complete a thought the title started.

The domain name is displayed on the card and is often the most legible element. A branded short domain does real work here, because the recipient is deciding whether to tap based mostly on who sent it and what host it appears to come from.

Decide deliberately whether a preview is wanted at all

A preview is not always desirable. A link to a document, an invoice or a personal booking may render a card that shows more than the sender intended in a group chat. If the destination is sensitive, either serve minimal metadata deliberately or accept that the first line of the page may be visible to everyone in the conversation.

The reverse also holds: a marketing link with no card looks like something to be suspicious of. Take a position on each kind of link you publish rather than letting the default emerge from whichever tags happened to be on the template.

Make it part of the pre-publication check

Add one step to whatever list you use before a campaign goes out: paste the real short link into a private chat in each messenger you expect it to travel through, and look at the card on a phone. It takes under a minute and it catches the wrong image, the missing title, the unfollowed redirect and the stale cache while all four are still cheap to fix.

Do this with the final link, not a test one, and do it early enough that changing the link is still possible. Once the link is in circulation, the cache has an opinion and you have lost the argument.