Link preview checker: see how your link looks when shared

Paste a link, short or long, and the link preview checker follows its redirects, reads the Open Graph tags on the final page, and shows the card WhatsApp, iMessage, Slack, LinkedIn and X will build from them. No sign-up.

Checked on SendURL's server, which keeps no copy.

How apps build a link preview

When you paste a link, the app fetches the page, reads the Open Graph tags in its <head> (og:title, og:description, og:image) and draws a card from them. No JavaScript runs, so tags a script adds after the page loads are invisible to it. Apple says so for Messages: previews “do not follow meta redirects, nor run JavaScript”, while server-side redirects are followed (TN3156).

That's why the checker follows redirects first. A short link is a redirect, so the card always comes from the page it lands on: paste snu.to/autumn-menu and you see the menu page's title and image, under the menu page's domain.

Each app documents a different part of this, and some document nothing:

What each app reads for a link preview, its image guidance and how its cache is refreshed, with sources
App	Reads	Image	Refresh	Source
Facebook	og:title, og:description, og:image, og:url (treated as the page's real address)	At least 1200 × 630, close to 1.91:1, never under 200 × 200, at most 8 MB	Sharing Debugger fetches the page again	Meta: images in link shares
LinkedIn	og:title, og:description, og:image	At least 1200 × 627, 1.91:1, at most 5 MB; under 401 pixels wide shows as a thumbnail	Post Inspector	LinkedIn Help: make your website shareable
X	twitter:card (required), then twitter: tags, falling back to og: tags	Large card 2:1, from 300 × 157 to 4096 × 4096, under 5 MB; JPG, PNG, WebP or GIF, no SVG	Re-read roughly every seven days	X developer docs (archived January 2025)
iMessage	og:title, og:image, an icon; follows server redirects, not meta refresh or JavaScript	At least 900 pixels wide; under 150 may be ignored. Reads the first 1 MB of the page	No tool	Apple TN3156 (2024-04-30)
Slack	oEmbed, then Twitter Card and Open Graph tags	No size published	Cached for about 30 minutes	Slack: robots
WhatsApp	Not published; previews the first link in a message only	No size published	No tool	WhatsApp Business Platform: text messages
Discord	Not published	No size published	No tool	None published

The tags a page needs

Nine tags cover every app above. X reads its own twitter: tags first and falls back to the Open Graph ones, so twitter:card is the only one it needs on top (X's Cards guide). The width and height let Facebook show the image on the very first share, before its crawler has downloaded it (Meta's image guidance).

<meta property="og:title" content="Autumn menu: six new dishes">
<meta property="og:description" content="Pumpkin ravioli, chestnut soup and four more, from 1 November.">
<meta property="og:url" content="https://example.com/autumn-menu">
<meta property="og:type" content="website">
<meta property="og:image" content="https://example.com/img/autumn-menu-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Six plates of autumn dishes on a wooden table">
<meta name="twitter:card" content="summary_large_image">

Write og:title as the headline, without the site name; that goes in og:site_name, as Apple's note asks. Make the image 1200 × 630 pixels and keep text out of its edges, since X crops it to 2:1 and Messages shows it at different sizes on different devices.

Refresh a preview that won't update

Every app keeps the card it built, so fixing the tags doesn't change a preview straight away:

Facebook and Messenger: paste the URL into the Sharing Debugger, which fetches the page again. Images are cached by URL, so a new image needs a new file name (Meta).
LinkedIn: run it through the Post Inspector. Posts already published keep their old preview (LinkedIn Help).
X: its crawler re-reads card tags roughly every seven days, and caches images by URL too (X's troubleshooting page, archived).
Slack: keeps a preview “for around 30 minutes” (Slack).
WhatsApp and iMessage: no refresh tool. Add something harmless to the link, such as ?v=2, so the app treats it as new.

Short links, previews and clicks

A preview fetch is a real request. On a short link it goes through the redirect like a tap does, and SendURL counts it as a click: a link pasted into a chat often has one before anyone has read the message. Checking a snu.to link here adds one too, recorded with the user agent SendURLLinkPreviewChecker/1.0. Why link previews count as clicks lists the fetchers by name and shows how to filter them out of your numbers.

WhatsApp and Messages build the preview on the sender's phone, according to a 2020 study of link previews by Talal Haj Bakry and Tommy Mysk, so a message to a group of 200 adds one preview fetch, not 200. More on that, and the UTM values for chat, in tracking link clicks in WhatsApp and SMS. For posts, LinkedIn link tracking covers one short link per place a link appears: the post, the first comment and each colleague's share.

Limits

The cards are approximations drawn from each app's usual layout; the apps change theirs often and differ between phone and computer. The checker reads the first 1 MB of the page (the same limit Apple gives for Messages), follows up to 10 redirects, reads the first 128 KB of the image for its size, and runs no JavaScript. Each visitor gets 10 checks a minute. Localhost, private networks and cloud metadata addresses are refused, even behind a public domain name.

Some sites send different HTML to the apps they know. When we checked on 15 October 2026, YouTube put its <title> near the top of the page for Facebook's crawler but about 750 KB in for everyone else. So a site can give WhatsApp or Facebook a card even when the checker finds none, and a site that blocks unknown bots can refuse the checker while still serving the apps.

The URL is sent to SendURL's server to fetch the page; the server stores and logs none of it. The site sees a request from SendURL's server with no cookies, not from you. The preview images on this page load from the site that hosts them, without a referrer.

Frequently asked questions

Why is my link preview not showing in WhatsApp?

WhatsApp doesn't publish its rules, so start with what the checker shows: the page has to answer without an error, carry og:title and og:image in the HTML it sends (not added later by JavaScript), and its image has to load for a bot. WhatsApp also previews only the first link in a message, as its Business Platform documentation says. If an old preview sticks after you fix the tags, add something harmless such as ?v=2 to the link so it counts as a new one. See tracking link clicks in WhatsApp and SMS.

How do I refresh a link preview after changing the image?

Paste the URL into Facebook's Sharing Debugger, which fetches the page again, and into LinkedIn's Post Inspector; Slack keeps a preview for about 30 minutes, and X re-reads card tags roughly every seven days. Facebook and X cache images by their URL, so give a new image a new file name. Posts already published keep the old preview.

What size should an og:image be?

1200 × 630 pixels (a 1.91:1 ratio), as a PNG or JPEG under 5 MB. That meets Facebook's recommendation of at least 1200 × 630 and its 200 × 200 minimum, LinkedIn's minimum of 1200 × 627, and Apple's advice of at least 900 pixels wide for Messages; X's large card crops it to 2:1, so keep text away from the edges.

Why does my short link show the wrong preview?

Apps follow the short link's redirect and build the card from the page it reaches, so a wrong title or image is usually that page's tags, or a preview the app cached before you changed the destination. Paste the short link above to see the page it lands on and the tags that page has. If the chain ends with a meta refresh or a JavaScript redirect, apps stop there and show that page's card instead. See the redirect checker, to trace the redirect.

Does a link preview count as a click?

On most link shorteners, yes: the app's preview fetcher follows the short link's redirect like a browser would, and SendURL counts that request as a click. So a link pasted into a chat often has a click before anyone has tapped it. See why link previews count as clicks.