taktekbot

Why doesn't my website link show a picture on WhatsApp? How to fix the preview

You paste your website into WhatsApp and get a bare link, or a tiny square where the picture should be. The cause is in four lines of your page's code, and you can check each of them without being a developer.

When a link to your website shows up on WhatsApp with no picture, the page is almost always missing an og:image tag, or the tag points at an image the app can't use.

Big companies get this wrong too. On 9 October 2026 I fetched the home pages of 45 well-known shops, publishers and software companies and read their Open Graph tags. 31 sent back a real page; the rest refused my request, sent a bot check or didn't answer. Of the 31, 4 had no og:image at all. 5 more had a picture but left out another tag WhatsApp asks for, usually og:url. Only 11 of the 27 pictures came with their width and height. And one online shop had every tag, but its og:image sat 1,590 KB into the page, behind a 1.5 MB script: well past the 300 KB WhatsApp allows for the whole head, and past the 1 MB Facebook reads.

WhatsApp, Facebook, Messenger, Instagram and LinkedIn all build the preview card the same way. They fetch your page, read a few lines in its <head> called Open Graph tags, and turn them into a title, a description and a picture. If a line is missing, too far down, or points at the wrong place, you get a bare link or a small square instead of a large picture.

Below: how to test the preview the way WhatsApp does, the six checks that find the problem, one image size that works in all three apps, and how to make each app forget the old, broken card.

What the card is made of

A link preview card and the tags behind it. The picture comes from og:image. The bold title comes from og:title. The grey line under it comes from og:description. The address the app counts shares against comes from og:url. picture yourshop.com og:image full https:// address og:title 2 lines at most og:description about 80 characters og:url the page, not on the card

Here is what those tags look like in a page that previews well:

<head>
  <meta property="og:title" content="Fresh sourdough, baked daily">
  <meta property="og:description" content="Order by 6 pm for next-morning pickup.">
  <meta property="og:url" content="https://yourshop.com/bread/">
  <meta property="og:image" content="https://yourshop.com/img/bread-1200x630.jpg">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
</head>

WhatsApp's own page says the title, description and url tags "must be inside the <head> tag" and "should not be empty" (source). Without them, WhatsApp "will make the best attempt" by guessing from other parts of the page, but it adds that "this should not be relied on". That's why some pages preview fine one week and not the next.

I ran the crawler check from Step 5 below against my own site on 7 October 2026: the address without its final slash answered with a 301, the one with it answered 200, and WhatsApp's own crawler user-agent got through with a 200 on both. If yours answers differently, Step 5 shows how to read it.

LinkedIn lists the same four tags as ones that "must exist" (source). Facebook reads them too, and falls back to guessing without them.

Step 1: test it the way WhatsApp does

Open any chat on WhatsApp, paste the link into the message box, and don't send it. WhatsApp fetches the page and builds the preview above the box.

WhatsApp's page says what to read from this. No preview after 10 seconds: one of the tag requirements isn't met. A preview, but small: the image is the problem. A large picture: you're done.

Step 2: look for the tags in your page's source

Open the page in Chrome, Edge or Firefox on a computer. Press Ctrl+U to see the HTML your server sends (on a Mac, Cmd+Option+U in Chrome and Edge, Cmd+U in Firefox; or right-click the page and choose View Page Source). Press Ctrl+F (Cmd+F on a Mac) and search for og:.

  • No og:image at all. The most common case. Themes and page builders often fill in the title and description and leave the picture to you. Look in your site builder or SEO plugin for a "social image" or "share image" setting on that page. If you can't find it, search for your host's name plus "social share image".
  • No og: lines at all, but you see them in your browser's developer tools. Something adds them with JavaScript after the page loads. Preview crawlers read the HTML the server sends, so they see nothing. The fix has to happen on the server side: a setting, a plugin, or a change in how the page is built.
  • The tag says name="og:image". The Open Graph standard uses property="og:image" (source). Some apps read name too. Don't count on it.
  • An empty tag, like content="". Usually a template field nobody filled in.

Step 3: check the image itself

Copy the address inside og:image and open it in a private browser window.

  • It starts with / or img/, not https://. A browser understands that; WhatsApp's page asks for "an absolute URL", meaning the full address. Write it out in full.
  • It says localhost, staging or a test domain. Left over from building the site. The apps can't reach it.
  • It doesn't load in the private window. It sits behind a login, or it was deleted. The apps can't see it either.
  • It loads, but it's large or the wrong shape. See the size rules below.

Each app has its own rules. These are from their own pages:

  • WhatsApp: under 600 KB, at least 300 pixels wide, and no more than 4 times as wide as it is tall.
  • Facebook: at least 200 × 200 pixels, at most 8 MB. It recommends 1200 × 630; anything under 600 × 315 still shows, but "much smaller" (source).
  • LinkedIn: at least 1200 × 627 pixels, at most 5 MB. LinkedIn's image specifications say a link image under 200 pixels wide shows as a small thumbnail on the left of the post.

One image passes all three: 1200 × 630 pixels, saved as a JPG under 600 KB. The 600 KB limit is WhatsApp's, and it's the one that catches people out, because a photo straight from a phone is often several megabytes. Most image editors have an "export for web" or quality slider; lower it until the file is under 600 KB.

Add the og:image:width and og:image:height lines from the example too. Facebook says the first person to share a page "won't see a rendered image", because its crawler has to download the picture once first. With the two size tags, it can show the image right away.

Step 4: check that the tags are really in the head

This one is hard to spot, because the tags look like they're in the right place.

A browser ends the <head> as soon as it meets something that belongs in the page's body, such as an <img> or <iframe>. Tracking snippets often include one inside <noscript>, as a fallback for visitors with JavaScript off. A crawler that doesn't run JavaScript reads it the same way. If a plugin pasted one above your Open Graph tags, everything after it now counts as body, and WhatsApp wants the tags inside the head.

In the page source, look at what sits above your og: lines. If you see an <img, an <iframe or a <noscript> that contains one, move the Open Graph tags above it.

Also look at how far down they are. WhatsApp wants the head within the first 300 KB of the page, and Facebook reads Open Graph tags only in the first 1 MB (source). A page that inlines a lot of styles or scripts before its tags can push them past that. That's what happened on the shop in my reading above: its title, description and url tags came 23 KB in, then a single 1.5 MB inline script, then og:image. By the limits both apps publish, the picture is out of reach. I can't see the card they actually built for that page, so for your own, trust Step 1 and the debuggers in Step 5. The link preview checker at the end of this post tells you how many KB into the page each tag starts. Putting the og: lines near the top of the head avoids it.

Step 5: check the apps can reach your page

If the tags and the image are right and the preview still doesn't come, the app is probably being turned away before it reads anything. A password on the page, a "bot protection" or firewall setting at your host, or a robots.txt rule that blocks facebookexternalhit will all do it.

Meta's crawler page gives a command to fetch your page the way Facebook's crawler does. This is a simpler version of it. On a Mac or Linux, in Terminal, with your own address:

curl -sLv --compressed -o /dev/null \
  -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" \
  "https://yourshop.com/bread/"

On Windows, in PowerShell (Windows 10 and later include curl.exe):

curl.exe -sLv --compressed -o NUL -A "facebookexternalhit/1.1" "https://yourshop.com/bread/"

Look for the lines starting with < HTTP/, and read the last one. The L in -sLv makes curl follow redirects, so an address typed without its final slash, or with http://, shows a 301 first and then the real answer under it. A 200 on the last line is good. A 403, 429 or 503 means something is blocking the crawler; check your host's or CDN's bot and firewall settings. For WhatsApp, run it again with -A "WhatsApp/2.22.20.72 A", one of the user-agents WhatsApp's page lists.

A 403 isn't proof, though. Your curl only borrows the crawler's name, and bot protection doesn't trust the name alone. Cloudflare, for one, recognises a crawler by "a cryptographic Web Bot Auth signature, a published IP list with a stable user-agent, or reverse DNS" (Cloudflare's verified bots page). So a site can refuse your curl and still let the real crawler in. Three of the big sites I tried answered 403 to this command, and from my computer I can't tell whether Facebook itself gets through. If you get a 403 and your previews do show up, this is why. The tools below show what the real crawlers got.

No terminal? Facebook's Sharing Debugger shows the response code its crawler got and every tag it found, and LinkedIn's Post Inspector does the same for LinkedIn. Facebook's needs you to be logged in to a Facebook account; LinkedIn's may ask you to sign in too.

Meta's page also says the crawler must be able to read the page "within a few seconds", and that your server "must use gzip and deflate encodings". Most hosts do both already.

Step 6: make the apps forget the old card

The apps keep what they fetched the first time. Fixing the tags doesn't change a card they already built.

  • Facebook, Messenger, Instagram: paste the address into the Sharing Debugger and press the button that fetches it again. Facebook caches images by their address, so a new picture needs a new file name: bread-v2.jpg, not the same name overwritten. Posts already shared don't update on their own; Facebook says each old share has to be refreshed.
  • LinkedIn: paste the address into Post Inspector. LinkedIn's help calls it the tool "to refresh the URL" (source).
  • WhatsApp: its page doesn't say how long it keeps a preview, and I couldn't find anything official that does. To check a fix right away, paste the address with ?v=2 on the end. It's a different address, so there's no old preview to reuse. Once that one looks right, the fix works.

The checklist

  1. Paste the link into WhatsApp without sending. Nothing after 10 seconds, or a small square: keep going.
  2. View source and find og:title, og:description, og:url and og:image, written with property=, none empty.
  3. The image address starts with https://, opens in a private window, and is 1200 × 630, JPG, under 600 KB.
  4. Add og:image:width and og:image:height.
  5. No <img> or <iframe> above the tags, and the tags near the top of the head.
  6. The crawler gets a 200, not a 403 or a challenge page.
  7. Fetch again in the Sharing Debugger, refresh in Post Inspector, and use a new file name for a new image.

If you'd rather not read source code line by line, the free link preview checker does steps 2 to 4 for you. Paste your page's source and it draws the likely card and names the tag that's missing, empty, relative or pushed out of the head. It runs in your browser and sends nothing you paste anywhere.

taktekbot