You open an event page in Safari and everything looks right: the headline, the artwork, the registration button. You send the link to a friend in Messages, and the preview shows a tiny logo. Or the wrong image. Or a gray card that gives them little reason to tap.
Start with the exact URL you sent. A page looking correct in your browser does not establish what information Messages can retrieve to build its card. The visible page, the preview metadata, and the image file are separate things to check.
What Messages Uses to Build a Link Preview
Apple's guide to rich previews in Messages identifies og:title and og:image as the metadata for a meaningful title and preview image. Without a large image, a card can show a title, domain, and small icon. A gray card alone does not prove the link is broken.
If these fields are unfamiliar, our Open Graph explainer walks through them. For troubleshooting, the useful question is whether the shared page publishes the title and image you actually want someone to see.
Why the Page Works in Safari but the Preview Fails
Messages does not run JavaScript or follow HTML meta redirects when creating previews. Apple says the metadata must be available directly on the linked page; server-side redirects are followed. A site that adds its preview tags only after scripts run can therefore look complete in Safari while providing insufficient information for a card. Apple also recommends consistent metadata across user agents. Read Apple's reachability guidance.
For a site you manage, inspect the HTML returned by the server. Searching the browser's live Elements panel can be misleading because scripts may already have changed it. Look for the intended og:title and og:image in the original response, and check whether redirects lead to the expected page.
Also open the URL in a private browser window. If it requires a login or displays an access challenge, investigate what an unauthenticated request receives. Keep private content private: a useful public title can explain what the resource is without exposing its contents.
If the Title Appears but the Image Doesn't
Copy the og:image URL and open it separately. Does it return the intended picture without requiring a session? Check for a missing file, expired image URL, permission error, or an HTML page where an image should be. A working page URL does not establish that its image URL works too.
Then check the file against Apple's resource guidelines: images should be at least 900 pixels wide; those under 150 pixels may be ignored or shown as icons. Icons should be square and at least 108 pixels per side. The main page resource is limited to 1 MB, and associated resources together are limited to 10 MB.
Use a clear image that represents this particular page. Apple recommends keeping generic branding in an icon and avoiding text-heavy preview artwork because cards appear at different sizes. It also explains that an icon can serve as a fallback when connectivity is poor. Apple's rich-link walkthrough shows that distinction.
For an event, try a recognizable photo of the venue or speaker rather than shrinking the entire event flyer into the card. Put the date and reason to attend in the message itself. Our Open Graph image-size guide helps you prepare reusable artwork; check the final crop in Messages before relying on it.
If Messages Shows the Wrong or an Old Image
First establish which image the public page currently advertises. Use the Open Graph checker on the exact shared URL, then inspect the image it finds. If that is the old artwork, fix the source page or image delivery before treating the problem as an app cache issue.
If the checker retrieves the right image, compare a fresh message with the earlier conversation. Record whether the incorrect card appears before sending, after sending, or only on the recipient's device. That gives you a more useful report than simply saying the preview is broken.
A metadata checker reports what its own request can retrieve. It cannot inspect the preview already displayed in somebody else's conversation. Avoid promising an immediate refresh of old messages, or treating a query-string change as a dependable purge method. For time-sensitive sharing, test the final URL and include enough context in your message for the recipient to understand it even without a card.
A Practical Checklist for Site Owners
Work through these checks before repeatedly changing the artwork:
- Copy the exact URL from the message, including its path and query parameters. Confirm it opens the intended resource.
- Inspect the returned HTML for the correct og:title and og:image. Check the response before browser JavaScript changes it.
- Open the image URL independently and confirm the file is accessible without signing in.
- Check image dimensions and resource sizes against Apple's guidelines.
- If you control the hosting, inspect request logs for redirects, access challenges, or failed image requests during your test.
- Send a fresh test message and inspect the received card. Record the device and operating-system version if results differ.
When You Don't Own the Destination
A merchant listing, partner article, or registration service may publish an image you cannot change. Ask its owner to update the preview metadata when possible. Meanwhile, a descriptive message still helps: explain what the link opens and why you are sharing it.
Another option is a shareable link with its own preview metadata. Prelinq lets you choose a title, description, and image while directing visitors to the original destination. Our guide to controlling previews for links you don't own explains that approach.
Messages still controls the card it displays. Custom metadata does not guarantee a particular iMessage layout or update a card already in a conversation. Before using a Prelinq for an important send, test that exact link in Messages and tap it to verify the destination. Keep its title and image faithful to the resource and identify the original publisher when that context matters.
Check the Received Message Before Sharing Widely
For a launch or announcement, send the final link to a test conversation first. Review the received title, image, and destination on the devices your audience uses. A correct checker result is a useful diagnostic; the received message is where you can see whether the card communicates what you intended.
Start by checking your page's metadata, fix any access or image problems, and then test in Messages. Give the link a short introduction that stands on its own, so the person receiving it knows why it is worth opening even if the preview is absent.