Telegram Link Preview: Why It Is Wrong and How to Fix It

You paste a link, hit send, and the box underneath it shows the wrong picture. Or the old headline. Or nothing at all. You fix the page, send the link again, and Telegram shows you exactly the same wrong thing.

That is not a bug in your page. The preview is built and stored on Telegram's servers, not in your app, which means the thing you are looking at was decided somewhere you cannot reach. It is also generated after the message is sent, it is cached, and the sender has more control over it than most people realise.

Here is what actually happens between pasting a link and seeing a box, and what you can do at each step.

What a Link Preview Actually Is

The box under your message is not part of your message. It is a separate object that Telegram attached to it, and treating it as separate explains most of the odd behaviour.

A separate object with its own identity

Every preview has its own identifier, its own stored copy of the address, and a display version of that address meant for humans rather than machines. Your message text and the preview travel together but they are not the same thing.

It also explains a small thing people find confusing, which is that the address stored with the preview and the address shown to the reader are two separate fields. A long tracking laden link can be shown tidily while still going where it always went. This is why deleting the text of a message and the preview under it are related but distinct operations, and why the preview can be present, pending, or empty while the message itself is perfectly fine.

What it can carry

A preview can hold a site name, a title, a description, an image, an author, a duration, an embedded player with its own dimensions, and in some cases a whole document. What appears depends on what the source page offered and on what type of thing Telegram decided it was.

None of those parts are guaranteed. A preview with a title and nothing else is a perfectly valid preview, and it usually means the page offered exactly that much. The box is a report on the page rather than a template you fill in.

The type decides the shape

Telegram classifies what it found, and that classification changes how the box is drawn and which buttons appear. An article, a video, a photo and an application listing all render differently. You cannot set the type from your end, you can only give the page enough signal that the right one is chosen.

This is also where a lot of wasted effort goes. People try to force a particular layout by changing the image or rewriting the title, when what they are actually fighting is a classification decision made from the page as a whole. The productive question is not how to get a bigger box, it is what kind of thing the page looks like from the outside. Answer that honestly and the box usually sorts itself out.

Who Builds the Preview, and Where

This is the fact that resolves the most frustration, so it is worth being precise about it.

Telegram fetches the page, not your reader

When a link is posted, Telegram's own systems fetch the address and build the preview. The people in the chat never touch your server, and their apps never parse your page. One fetch produces one preview that everybody then sees.

For anything private this is worth pausing on. Posting an internal address into a chat causes that address to be fetched by an outside system, whether or not anybody clicks it. That is not a security failure, it is how previews work, but people are regularly surprised by it. That single detail explains why a page fixed on your side stays broken in the preview, and why the person who says it looks fine for them is usually looking at a different cached state rather than a different page.

It only processes ordinary web pages

The fetching side only handles pages served as ordinary hypertext. An address that returns a file, a redirect chain that ends somewhere unexpected, or a page that requires a session before it shows anything will not produce a useful preview, because what comes back is not a page it can read.

There is a whole category of modern site that falls foul of this without anyone noticing. Pages that build themselves in the browser after loading hand the fetch an almost empty shell, because the fetch does not wait around for the page to finish assembling itself. The reader sees a complete article and the preview sees a blank frame, and both are looking at the same address. If your previews are consistently empty and your pages are consistently fine, this is the first thing to check.

The preview is asynchronous

The message can exist before its preview does. Telegram has a specific state for this, meaning the preview is currently being generated, and it records when that processing started. In practice you see the message appear and the box fill in a moment later, or not at all if the fetch failed.

It also means a preview can arrive after the moment anybody was looking. In a busy channel the post has already scrolled past by the time the box fills in, which is one more argument for checking the link before you send rather than after. Anyone testing previews should send once, wait, and look again before concluding anything. A large share of reported preview failures are people judging a box that had not finished being built.

Why the Preview Is Sometimes Missing

No box at all is a different problem from a wrong box, and the causes barely overlap.

The page never answered

If Telegram's fetch failed, timed out, or was refused, there is nothing to show. Pages behind a login, behind aggressive bot filtering, or on servers that block unfamiliar visitors all land here. Your browser opening the page proves nothing, because your browser is not what fetched it.

Servers that treat unfamiliar visitors as suspicious are the most common version of this now. The protection is doing its job and the preview is the collateral damage, and the fix lives in your server configuration rather than anywhere in Telegram.

The page had nothing to offer

A page that returns successfully but carries no title, no description and no image gives the preview builder nothing to build with. The result is either a bare address or no box at all, which reads as a failure but is actually an accurate report of an empty page.

Fixing this is the cheapest work available to anyone who publishes. Three lines of metadata decide how every future share of that page looks, on this platform and on several others, and they are usually written once and never touched again.

Somebody turned it off

Previews can be disabled per message by the sender. If a link consistently shows no box in one channel and a full box everywhere else, the difference is usually a setting on the sending side rather than anything about the link.

This is worth checking before assuming a link is broken. Post the same address in a private chat with yourself and see what happens. Two different results from the same address means the difference is in the sending, not in the page.

Why It Shows the Wrong Thing

The wrong image, an outdated headline, or somebody else's branding entirely. All three have the same root.

You are looking at a stored copy

Previews are cached, and the cached copy is keyed to the address rather than to the current state of the page. Telegram even carries a value on the preview specifically for caching purposes. What you see is what the fetch found the first time, which may have been months ago.

The mental model that helps is to stop thinking of the preview as a window and start thinking of it as a photograph. Somebody took it once, at a moment you did not choose, and everyone since has been handed a copy of that photograph. Nothing you do to the subject changes the picture. The only way to get a new picture is to make the system take one, and the address is what decides whether it bothers. This is why the fix that works on every other platform, editing the page and trying again, does nothing here. You are not asking for a new fetch, you are being handed the old answer faster.

The address is not the address you think

Tracking parameters, shorteners and redirects all mean the address that got fetched may not be the one you meant. Two links to the same article with different parameters are two different previews as far as the cache is concerned, and one of them can be correct while the other is stale.

Shorteners deserve particular suspicion here, because they add a redirect the fetch has to follow and a second place where things can go wrong. A preview that shows the shortener rather than the destination is telling you the chain did not resolve the way you assumed. That also gives you the crudest working fix, which is to change the address slightly so it is treated as new. It is inelegant and it works.

The page serves different content to different visitors

Pages that vary by region, by device, or by whether the visitor looks like a person will hand the preview builder something the reader would never see. If your preview shows a cookie banner, a consent wall or a language you did not expect, that is what was served to the fetch.

Consent walls are the usual culprit in Europe and the usual surprise for the person who built the page. They never see the wall because they accepted it months ago, and the fetch meets it fresh every single time. Our note on what links leak about you covers the related habit of checking what a link actually does before sharing it.

Why It Will Not Update

The single most searched complaint in this whole area, and the honest answer is more limited than most articles admit.

There is no documented refresh

Telegram's public documentation describes the caching but does not publish a supported way for an ordinary user to force a new fetch. Anyone telling you there is an official button is describing something that is not written down anywhere.

It is worth saying plainly why this matters rather than treating it as trivia. A workaround that is not documented is a workaround that can stop working without notice, and building a publishing process on top of one is how teams end up improvising on a launch day. Knowing which parts of your process rest on documented behaviour and which rest on convention is the difference between a system and a habit that has not failed yet. The widely used community method is to send the address to a particular Telegram service that regenerates it, and it usually works. It is worth knowing and worth being honest about, because it is not part of the documented platform and nobody owes you a working version of it tomorrow.

What reliably works instead

Changing the address does. A different parameter, a different path, a trailing marker that your server ignores, all of these are new addresses as far as the cache is concerned, and a new address means a new fetch. For anything time sensitive this is the approach that does not depend on somebody else's service staying up.

Pick one convention and use it everywhere rather than improvising per link. A single parameter name your server ignores, appended when you need a fresh fetch, is a habit that takes ten seconds to adopt and removes an entire class of confusion later.

Plan for it before you publish

The practical lesson is that the first time a link is shared is the version that sticks. Getting the title and image right before the link goes anywhere costs nothing. Fixing it afterwards costs you either a new address or a workaround you do not control. Our note on writing posts that actually sell treats the preview as part of the post for exactly this reason.

The same logic applies to images. Replacing a picture at the same address after the link has circulated does not update anything already cached, so the version that went out first is the version most people will keep seeing.

Which Link Gets Previewed

A message with several links does not produce several boxes, and the rule for which one wins is simple once you know it.

The first one, by default

If nothing is specified, the preview is built from the first address found in the text. Everything after it is just a link. This catches people who lead with a source citation and then wonder why their own page is not the one being shown.

It is a surprisingly common failure in announcements, where the polite instinct is to credit the source at the top. That instinct puts somebody else's box under your message, and nobody notices until the post is already out.

You can name a different one

The sending side can specify which address the preview should use, independently of where it sits in the text. That means the box under your message does not have to correspond to the first thing you mentioned, and for anything promotional it usually should not.

This is one of the few genuinely free wins available. The link you want previewed does not have to move in the text, so you can keep the sentence you wanted and still get the box you wanted.

Order the text around the answer

Once you know the first link wins by default, the writing changes. Put the link you want previewed first, or specify it deliberately, and treat the rest as plain references. Composing the message and then hoping is how most people end up with a preview of somebody else's site under their own announcement.

There is a simple discipline that catches most of it. Before sending, ask which single address you would want a stranger to see a picture of, and make sure that is the one the message is going to use.

Turning the Preview Off

Sometimes the box is the problem rather than the solution.

A per message switch

Previews can be disabled for a specific message, which leaves the link clickable and removes the box entirely. It is a property of that message rather than a global setting, so it has to be chosen every time.

Because it is per message, it also cannot be a channel wide policy without somebody remembering it every time. Teams that care about this usually write it into whatever checklist they already use rather than trusting recall.

When turning it off is right

Short operational messages, lists of several links where one box would be arbitrary, and anything where the preview image undercuts the message. A serious announcement with a cheerful stock photograph attached to it reads worse than the same announcement with no picture at all.

The other case is a link everyone in the room has already seen. A preview under the fifth mention of the same address is pure repetition, and removing it makes the conversation noticeably easier to read.

What it does not do

Disabling the preview does not hide where the link goes, does not stop anyone opening it, and does not remove it from anything already cached. It is a presentation choice, not a privacy measure, and treating it as the second thing is a mistake worth avoiding.

It is worth being blunt because people do use it this way. Someone who wants to know where a link goes can simply open it, and disabling the preview only removes the convenience of finding out beforehand.

Making the Image Bigger or Smaller

Preview size is not fixed, and this is the part almost nobody knows exists.

The size is negotiable

A preview carries a flag saying whether the size of its media can be changed at all. When it can, the sender can ask for the image to be enlarged or shrunk, and the same link can therefore appear as a thumbnail in one message and a wide banner in another.

The practical consequence is that two channels can share the same article and look completely different doing it. One reads as a news item, the other as an advertisement, and the difference was one setting rather than any effort.

Which one to choose

Large media turns the message into something closer to an advertisement, which is right for a launch and wrong for the fourth link you have posted this hour. Small media keeps the text primary and the link supporting. Most channels pick one by accident and never revisit it.

A reasonable default is small media for routine posts and large for the ones that matter. Reserving the big treatment makes it mean something, which is exactly what channels that enlarge everything have thrown away.

Not every link offers the choice

The flag exists because the option is not always available, and what the page provided decides it. A page whose only image is tiny cannot be shown as a banner no matter what the sender asks for, which is a page problem rather than a Telegram problem.

When it matters, the fix is on the page. Publishing a reasonably large sharing image gives every future share the option, and omitting one quietly caps what anyone sharing your work can do with it.

Putting the Preview Above the Text

A smaller control with a disproportionate effect on how a message reads.

The preview can lead

The sending side can ask for the preview to appear above the message text rather than below it. The message becomes an image with a caption instead of a paragraph with an attachment, and in a fast scrolling channel that is a genuinely different object.

It also changes what gets read. With the image first, the picture does the persuading and the text explains it. With the image last, the text has to carry the message on its own and the picture confirms it.

When leading with it helps

When the image is the argument. A product shot, a chart, a screenshot of the thing you are announcing. When the words carry the argument and the image is decoration, keeping the preview below is the calmer and usually better choice.

The test is whether somebody who saw only the image would understand the point. If yes, lead with it. If the image is a generic photograph chosen by whoever built the page, putting it first is giving the best position to a stranger's stock library.

Consistency matters more than the choice

Readers learn the shape of your posts faster than they learn your topics. Alternating between the two layouts at random makes a channel feel unedited, which is a cheap thing to fix and an odd thing to leave broken. Our guide on planning what a channel posts covers the rhythm side of this.

What the Preview Pulls From Your Page

If you control the page, this is where the work actually is.

Title, description, image

These three do most of the job. Telegram reads what the page declares about itself and uses it, which means the preview quality is largely decided by the metadata you shipped rather than by anything you do in the chat.

Writing them for the chat rather than for search engines is the small adjustment most publishers never make. A title that works in a search result is often too long for a preview box, where it simply gets cut.

The site name is separate

The preview also carries a short name for the site, which is what gives the box its small label. Pages that never set one show something less tidy, usually a bare domain, and the difference between those two is the difference between a preview that looks published and one that looks scraped.

It is one line of metadata and it changes how trustworthy the box looks at a glance. Given how much of this platform's traffic moves through forwarded links, that line is doing more work than its size suggests.

Video, audio and embeds are their own case

Some links produce a playable object rather than a picture, with its own address, its own type and its own dimensions. That is why a video link behaves so differently from an article link in a chat, and why testing one tells you nothing about the other.

Anyone whose content is mostly video should test on video links specifically, because everything you learned from article links may simply not apply. Our piece on what runs inside Telegram itself covers the wider set of things that open without leaving the app.

Instant View, the Other Layer

Sometimes the preview comes with a button that opens a stripped down version of the article inside Telegram. That is a separate system sitting on top of the preview.

It is stored with the preview

When a page qualifies, its formatted contents are carried along with the preview itself. The reader never leaves the app, and your server never sees the visit.

That is convenient for readers and inconvenient for anyone counting visits, since a read that never touches your server is a read you cannot measure. Whether that trade is worth it depends entirely on what the page is for.

It works by domain templates

Qualification is not automatic and it is not per page. Somebody writes a template for a domain describing where the title, the body and the images live, and the system applies that template to pages on that domain. No template means no button, regardless of how well built the page is.

This also means the button can appear on your links without you having done anything, because somebody else wrote a template for your domain. Most publishers discover the feature that way rather than by choosing it.

It only handles ordinary pages

The processing side only works with pages served as ordinary hypertext, which rules out anything that renders itself after the fact or hides behind a wall. Publishers who care about this build a plain version of the page specifically so the fetch has something to read.

Previews in Channels and Groups

The mechanics are the same everywhere. What changes is how much the box costs you.

In a channel the preview is the post

Most channel posts are a line of text and a link, which means the preview image is the largest thing in the message and the first thing anyone sees while scrolling. Treating it as an afterthought is treating your own post as an afterthought.

Look at your own channel with this in mind and the picture is usually unflattering. Post after post where the only visual is whatever image somebody else chose for their page, sized however the system decided, sitting under a line of text that assumed the reader would read it first. Nobody planned that. It is simply what happens when the preview is treated as something that appears rather than something you chose.

In a group it is noise

A busy group with a preview under every shared link becomes hard to read. This is the situation where turning previews off for your own messages is a courtesy rather than a preference, and where members quietly appreciate the people who do it.

There is a social pattern worth noticing here. The people who disable previews in busy rooms tend to be the ones who read those rooms most closely, because they are the ones who feel the clutter.

Forwarding carries it along

A forwarded message keeps its preview, including a stale one. Something you posted six months ago can still be circulating with an image you replaced long ago, and there is no operation on your side that reaches into copies already sent. Our piece on how channel reach actually builds covers what forwarding does for you when the content holds up.

The practical consequence is that a preview is more permanent than the page behind it. Pages get rewritten, redirected and retired; the boxes that went out with them keep circulating exactly as they were.

What a Preview Costs You

Every box has a price, and it is not always paid in pixels.

It tells people where they are going

A preview is a small honesty mechanism. It shows the site name and the title before anyone clicks, and links that lead somewhere other than they appear to are exposed by it. That is a good thing, and the people who hate it most are usually the ones with something to hide. Our write up on how Telegram scams are actually run covers the deception side properly.

Reading the site name before clicking is a habit worth building and worth teaching anyone you work with. It costs nothing and it catches the overwhelming majority of links that are not what they claim.

It can leak the wrong thing

Whatever your page declares about itself is what appears in somebody's chat. Staging domains, internal tools and half finished pages all announce themselves happily. Checking what a link looks like before sending it into a customer conversation takes ten seconds and occasionally saves an afternoon.

Staging addresses are the classic case. They are usually configured with whatever placeholder text somebody typed in a hurry, and that text is what appears under your message in a customer's chat.

It puts a stranger's picture in your message

When you link somebody else's page, their image sits under your words carrying your name. Most of the time that is fine. When it is not, disabling the preview is the fix, and it is the reason experienced operators disable it far more often than newcomers expect.

Previews at Scale, When You Send Thousands

Everything above matters more the more messages you send, and a few things only appear at volume.

One preview, many recipients

The preview is built once and served to everyone, so a thousand recipients do not produce a thousand fetches of your page. That is convenient, and it also means one bad preview reaches a thousand people identically. There is no version of this where some of them see the corrected one.

The scale changes the stakes rather than the mechanics. A wrong preview in a chat with three people is an embarrassment you fix by sending another message. The same wrong preview across a campaign is the only impression most of those people will ever form, because they are not reading a conversation, they are seeing one message once. Getting it right beforehand is not perfectionism at that point, it is the entire quality process.

Get it right before the first send

Because the first fetch decides what everybody sees, campaign links deserve a test send to yourself before anything goes out. Send it, look at the box, and only then start. This is the single cheapest quality check in the whole business and it is skipped constantly. Our mass direct messages work is built around that ordering, since a preview cannot be corrected mid campaign.

Sending to yourself has a second benefit worth mentioning. You see the message the way the recipient will, at their width, with their spacing, rather than the way it looked in the box you composed it in.

Parameters change the preview, not just the tracking

Adding a tracking parameter per campaign creates a new address, and a new address means a new fetch and a new cached preview. That is mostly good, since it gives each campaign its own current preview, but it also means a broken page produces a fresh broken preview every time rather than reusing an old good one. Anyone measuring clicks with channel analytics is already generating these addresses and should know they carry a preview consequence.

The safe order is to fix the page first, then generate the campaign addresses. Doing it the other way round means every tracked variant carries a fresh copy of whatever was wrong.

What Operators Get Wrong About Previews

The mechanics are settled. These are the judgement errors that show up repeatedly.

Debugging the page instead of the cache

Hours go into fixing metadata that was already correct, because the preview being shown was fetched before the fix and will never be fetched again. Check whether you are looking at a cached copy before you touch the page. It is the first question, not the last.

A quick way to tell them apart is to try an address that has never been shared before. If a brand new address previews correctly, the page is fine and you have been fighting a stored copy.

Letting the preview write the message

People paste a link, see a decent box appear, and consider the post finished. The preview is a summary of somebody else's page, including when that somebody is you six months ago. The message still has to say why this link is in front of this audience today, and no automatically generated box does that.

The pattern is easy to spot in other people's channels and hard to spot in your own. A run of posts where every message is one line and a box is a channel that stopped writing and started forwarding.

Copying a channel and inheriting its previews

Duplicated posts bring their links and therefore their previews with them, including the stale ones and the ones pointing at the original owner's tracking. If you are mirroring content with channel clone, the links are the part to review rather than the wording. Our note on sending at volume without getting flagged covers the sending side of the same discipline.

It is also how somebody else's tracking ends up in your numbers. The link works, the post looks right, and the clicks are being counted somewhere you have no access to.

Treating the box as free real estate

A preview is persuasive because it looks like Telegram vouched for it, and that borrowed authority is exactly why it deserves care. If the image, title and site name do not describe what a person gets after clicking, the preview is not marketing, it is a promise you did not intend to make. When a campaign genuinely needs something the standard box cannot do, that is where a custom build starts rather than where a workaround does.

The uncomfortable part is that this works. A preview with a credible site name and a confident headline moves people, which is precisely why the standard for what goes in one should be higher than the standard for what goes in your own sentence. Anything you would not say in the message itself does not become acceptable because a machine rendered it in a grey box under your name.

Frequently Asked Questions

Why is my Telegram link preview not showing?

Either the fetch failed, the page offered nothing to build from, or the sender disabled previews for that message. Your browser opening the page proves nothing, since Telegram fetches it separately from its own systems and can be blocked when you are not.

Why does the preview show old content?

Previews are cached against the address, so what you see is what the first fetch found. Editing the page does not trigger a new fetch, and the old copy keeps being served to everybody who sees that link.

How do I refresh a Telegram link preview?

There is no documented way to force one. Changing the address, even by adding a parameter your server ignores, reliably produces a new fetch. A community service exists that regenerates previews and usually works, but it is not part of the documented platform.

How do I turn off the link preview?

Disable it for that specific message when you send it. The link stays clickable and the box disappears. It is chosen per message rather than once globally, so it has to be set each time.

Which link is used when a message has several?

The first address in the text, unless the sender specifies a different one. That is why a message that opens with a citation often previews the citation rather than the thing being announced.

Can I make the preview image bigger?

Yes, when the preview allows it. The sender can request enlarged or shrunk media, and the preview itself carries a flag saying whether its size can be changed at all. Pages whose only image is small cannot be shown as a banner.

Can the preview appear above my text?

Yes. The sending side can ask for it, which turns the message into an image with a caption rather than text with an attachment underneath. It reads very differently in a fast moving channel.

What decides the title and image in a preview?

What the page declares about itself. Telegram reads the page's own metadata and builds the box from it, so preview quality is mostly decided before the link is ever shared.

What is Instant View and why do only some links have it?

It is a stripped down version of an article that opens inside Telegram. It works from templates written per domain, so a domain without a template gets no button no matter how well the page is built.

Do previews work the same in groups and channels?

The mechanics are identical everywhere. What differs is the cost, since in a channel the preview is usually the largest part of the post, and in a busy group it is mostly clutter under everybody's shared links.