The title, image, and description shown in a social media link preview card come from information the destination page itself provides — not from any independent check by the platform — which means a scammer controlling that destination page can set the preview to say almost anything, regardless of what the page actually contains. The domain text usually shown beneath the preview is worth reading carefully, but it is not universally guaranteed to be more trustworthy than the rest of the card: depending on the specific platform, that displayed address may be the actual link you would land on, or it may itself be pulled from a self-reported tag the page supplied — see below for which is which, where it can be determined.
How link preview cards actually work
When you share a link on most social platforms, the platform briefly visits the destination page and reads specific metadata tags the page has published about itself — fields intended to describe the page’s title, description, and image for exactly this kind of preview. This system exists for entirely legitimate reasons, letting publishers control how their content appears when shared. The same system gives a malicious page owner full control over what their preview card displays, independent of what actually loads when someone clicks through.
What this means for safety
A preview card reading “Free iPhone Giveaway — Apple Official” with a convincing image proves nothing about the actual destination; that text and image were simply supplied by whoever controls the linked page, the same way a return address on an envelope can be written to say anything. The domain or URL text shown beneath the headline is worth checking, but confirm what it actually reflects before relying on it — some platforms display the link’s real destination address directly, which is a meaningfully more reliable signal, while others render a self-reported og:url value supplied by the page itself, which a page’s owner can set independently of where the link truly leads, the same as the headline and image. When you are not certain which behavior a given platform uses, previewing the raw link directly — see How to Read a URL: Every Part Explained in Plain English — is the more dependable check.
Step-by-step: evaluating a link preview
- Locate the domain text on the preview card — usually shown in smaller, muted text beneath the headline and image.
- Read that domain carefully using the method in How to Read a URL: Every Part Explained in Plain English, watching for the lookalike patterns described in Lookalike Domains and Homograph Attacks: What to Check.
- Treat the headline, description, and image as unverified marketing copy written by whoever controls the destination — not as confirmed facts.
- If the preview claims to be from a well-known brand but the domain does not match that brand’s actual known domain, do not click through.
A worked example
A post shared in your feed shows a preview card: headline “Bank of Example — Security Alert,” a bank-branded image, and small domain text reading bofexample-alerts.net. Applying the steps above: the headline and image can be set to anything by the page’s owner, but the domain text is the one part reflecting the actual destination — and it does not match the real bank’s known domain. This is a strong signal to avoid clicking, regardless of how convincing the headline and image appear.
Where this matters most
- Fake giveaway posts — see Fake Giveaways on Instagram, TikTok, and Facebook
- Links shared in Facebook posts and comments — see How to Check a Suspicious Facebook Link Before Opening It
- Any shared link where the preview card, not the raw URL, is what you actually see first
The actual mechanism, per the Open Graph specification
The official Open Graph protocol specification defines a small set of meta tags a page can include in its own HTML — og:title, og:image, og:url, and og:type among them — that a platform reads when generating a preview card. This includes og:url itself: a page declares what it considers its own canonical address, and nothing in the specification requires that declared address to match the address you actually followed to reach it. The specification is simply a data format; it includes no verification step confirming any declared field, including the URL, accurately represents the page. A page can declare any og:title, og:image, and og:url it wants, entirely independent of what a visitor who clicks through will actually see. This is not a flaw exploited by scammers so much as the protocol working exactly as designed for its original purpose — letting a page’s own owner control how it is represented — with the side effect that a malicious page’s owner has that same control over every field, including the one that looks like an address.
Limitations
Some platforms apply light validation or caching to preview data, and a small number restrict which metadata a page can control, but this is not a security check in any meaningful sense — it exists to keep preview cards looking consistent, not to verify the destination’s legitimacy. Do not treat a normal-looking, well-formatted preview card as any kind of endorsement of the link’s safety.
Frequently asked questions
Can the preview image itself be dangerous?
The image displayed in a preview card is just a picture and does not carry the same interactive risk as the destination page itself. The concern is what happens if you click through based on a misleading headline or image, not the image display itself.
Do all platforms show the domain in the preview card?
Many major platforms show at least some version of a domain or URL, though its size, placement, prominence, and — as covered above — whether it reflects the real destination or a self-reported og:url value all vary by platform. If a platform does not show it clearly, or you are unsure which behavior it uses, use the long-press or hover method in How to Tell Whether a Link Is Safe Before You Click on the link itself instead.
Why would a preview card ever be wrong for a legitimate site?
Sometimes a legitimate site’s preview data is outdated, cached, or simply not set up carefully, leading to a mismatched but harmless preview. This is why the domain check matters more than assuming any mismatch automatically means malicious intent — though a mismatch is still worth pausing on.
