How to make a link preview animate in iMessage, Slack, WhatsApp, Discord and Telegram

Checked November 2026. “Verified by us” means we saw it animate in that app ourselves; everything else comes from the linked docs or observations.

TL;DR

No single tag animates everywhere. Put the animated GIF itself in og:image (Slack shows it moving) and a downloadable H.264 MP4 of the same loop in og:video (iMessage downloads and plays it). Serve both as plain files at stable HTTPS URLs, with the tags in the first HTML response. WhatsApp's spec only describes a thumbnail for links, so expect it to stay still (we haven't tested it); when motion matters there, share the GIF file instead of the link. Discord and Telegram can show animated media, but which tags they use for an ordinary site isn't documented: test them.

Per app

Copy-paste <head>

Use absolute HTTPS URLs and the real width and height of each file. Leave out the og:video and twitter:player:stream lines when you have no MP4.

<meta property="og:type" content="video.other">
<meta property="og:url" content="https://example.com/m/abc123">
<meta property="og:title" content="Build passed first try... suspicious">
<meta property="og:description" content="A captioned GIF">
<!-- Slack, Discord: the animated GIF itself, not a screenshot -->
<meta property="og:image" content="https://example.com/m/abc123.gif">
<meta property="og:image:secure_url" content="https://example.com/m/abc123.gif">
<meta property="og:image:type" content="image/gif">
<meta property="og:image:width" content="480">
<meta property="og:image:height" content="360">
<meta property="og:image:alt" content="Build passed first try... suspicious">
<!-- iMessage: a downloadable H.264 MP4 of the same loop -->
<meta property="og:video" content="https://example.com/m/abc123.mp4">
<meta property="og:video:secure_url" content="https://example.com/m/abc123.mp4">
<meta property="og:video:type" content="video/mp4">
<meta property="og:video:width" content="480">
<meta property="og:video:height" content="360">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://example.com/m/abc123.gif">
<meta name="twitter:player:stream" content="https://example.com/m/abc123.mp4">
<meta name="twitter:player:stream:content_type" content="video/mp4">

Serve the media from their own URLs, the same bytes to every client:

• /m/<id>.gif: the GIF bytes with Content-Type: image/gif and a Content-Length. Missing files get a 404, never an HTML page with status 200.
• /m/<id>.mp4: Content-Type: video/mp4, Accept-Ranges: bytes and correct 206 responses to Range requests (Apple's players ask for byte ranges). Put the moov box at the front (fast start).
• Don't swap in GIF bytes for crawlers at the page URL by sniffing user agents: they overlap (Telegram's says “like TwitterBot”) and a cache can serve the wrong one.

WhatsApp: share the file, not the link

WhatsApp's spec describes the link card as a thumbnail, so plan for a pasted link to stay still (not tested by us). The Web Share API can hand the GIF to the share sheet as a file instead, so it goes out as media rather than a link card. We haven't recorded the result in WhatsApp yet. Fetch the file before the tap: browsers only allow navigator.share() shortly after a user gesture.

// Fetch the GIF on page load, so the tap can call share() at once.
let file = null;
fetch("/m/abc123.gif")
  .then((r) => r.blob())
  .then((b) => {
    const f = new File([b], "abc123.gif", { type: "image/gif" });
    if (navigator.canShare?.({ files: [f] })) file = f;
  });

button.onclick = async () => {
  if (file) return navigator.share({ files: [file], text: "Remix it: https://example.com/m/abc123" });
  if (navigator.share) return navigator.share({ url: "https://example.com/m/abc123" });
  await navigator.clipboard.writeText("https://example.com/m/abc123");
};

Desktop browsers without file sharing fall back to sharing or copying the link.

Making the MP4 in the browser (WebCodecs)

You don't need a server-side ffmpeg. We draw each GIF frame to a canvas, encode it with VideoEncoder as H.264 Constrained Baseline (avc1.42001f, about 1 Mbps, a keyframe every 2 seconds) and mux it with mp4-muxer using fast start. Check VideoEncoder.isConfigSupported() first; H.264 needs even width and height, so crop a pixel if needed. If the browser can't encode H.264, the file is over 4 MB, or encoding takes more than 20 seconds, we publish without an MP4 and the page simply has no og:video.

How to test

# What the crawler sees: the tags must be in the first HTML response, no JavaScript
curl -s -A "Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)" https://example.com/m/abc123 | grep -E 'og:|twitter:'
curl -s -A "WhatsApp/2.22.20.72 A" https://example.com/m/abc123 | grep 'og:image'

# The media URLs: right type, real bytes, and a 206 for a Range request
curl -sI https://example.com/m/abc123.gif
curl -s -o /dev/null -w '%{http_code} %{content_type}\n' -H 'Range: bytes=0-1023' https://example.com/m/abc123.mp4

• Use a new URL for each attempt: apps cache previews (Slack for about 30 minutes, and it won't unfurl the same link twice in a conversation within an hour).
• Send to yourself or a private test chat, and record a few seconds of the unopened preview. One screenshot can't prove motion; two frames that differ can.
• WhatsApp's docs say to type the URL and wait up to 10 seconds for the preview to appear.
• A crawler hitting your server proves it fetched the page, not that the app animated it.

We learned this building vibe gifs, a GIF caption/remix app: gifs.agentswarm.space. Live example share page: /m/D5HcmZ8.