iMessage runs no crawler you can query and ships no debugger, so the rules that decide whether your link arrives with a picture live in a single Apple technote — and they are stricter than anything Facebook or LinkedIn publishes. Apple asks for an og:image at least 900 pixels wide and keeps the page itself under 1 MB. We fetched 36 live pages and the image files behind them to see how many clear those bars. Six pages broke the 1 MB page ceiling. Three images landed under the 900 pixel floor. One og:image URL no longer resolves at all.
Short version: 1200×630 PNG, under 300 KB, tags in the server HTML, page under 1 MB. The rest of this post is the measured support for those four numbers.
What the Messages App Actually Fetches
By default a link in Messages renders as a gray bubble holding the page title, the domain, and a small icon — no picture. Images appear only when the page publishes Open Graph metadata, and Apple's technote TN3156: Create rich previews for Messages spells out that contract. It is short, and two sentences in it decide most real-world outcomes: link previews do not run JavaScript, and they do not follow meta-refresh redirects. Server-side redirects are followed. A meta refresh is not.
That first rule kills more previews than missing tags do. Any page that injects its Open Graph tags client-side — React Helmet, a tag manager, a consent gate that loads content after a click — shows Apple the same gray bubble as a page with no tags whatsoever. It also shaped how we measured. Every URL in this sample came back as raw server HTML with nothing executed, which is exactly what the Messages client receives.
Real talk: four of the 40 URLs we requested answered 403 to a desktop Safari user agent and were dropped from the sample — nytimes.com, producthunt.com, etsy.com, openai.com. Nobody was scraping hard. The edge simply decided. Whatever Apple's client gets from those hosts, no og:image tuning on the publisher side changes it, and if your own WAF treats unidentified clients as hostile, the gray bubble you see is a firewall talking, not a metadata bug.
Apple's Numbers, and Where They Differ
TN3156 lists its limits in a section called resource usage guidelines, with the caveat that they may change. As of the April 2024 revision they read like this:
| What | Apple's number | What happens at the edge of it |
|---|---|---|
| og:image width | At least 900 px | Below the bar, the preview looks under-fed or drops the image |
| Tiny images | Under 150 px wide | May be ignored, or drawn as an icon instead |
| Icon fallback | Square, 108 px per side | apple-touch-icon or favicon gets used when no usable image exists |
| The page itself | 1 MB main resource | Hard ceiling on the HTML the client will parse |
| Everything attached | 10 MB total | Icons, images and videos counted together |
| Aspect ratio | Not stated | Apple never names one, unlike every social platform's spec sheet |
That missing aspect ratio is the quiet difference. Plenty of guides hand out a 1.91:1 rule as if Apple published it; the technote does not. Apple also warns against putting text in preview images, because the same card renders at wildly different sizes on an iPhone SE and a Mac, and says plainly to keep the site name out of og:title and put it in og:site_name instead. Both of those are authorship rules rather than pixel rules, and the sample shows how well the web follows them.
What 36 Live Pages Actually Ship
Method: 40 well-known URLs, plain GET with a desktop Safari user agent, meta tags parsed out of the server HTML, then every og:image downloaded and measured at byte level rather than trusted from its tag. 36 pages were readable, 33 declared an og:image, and 31 images returned dimensions we could parse. Widths came back like this:
| Image width | Pages | Verdict against Apple's 900 px guideline |
|---|---|---|
| Under 150 px | 0 | Nobody shipped something that small |
| 150–899 px | 3 | Under the floor: arstechnica 512, ogp.me 300, wikipedia 250 |
| 900–1199 px | 3 | Clears the bar, nothing to spare |
| 1200–1399 px | 18 | The de facto standard, 16 of them exactly 1200 |
| 1400 px and up | 7 | Up to 2800 px on github.com's Next.js repo page |
Median width: 1200 px. Median file size: 72 KB. Formats split 21 PNG, 9 JPEG and one GIF. Not a single image used a plain http:// URL, which is worth knowing if you are wondering whether Apple will fetch an insecure image — in this sample the question never came up.
Two files ignored sane file sizes: figma.com ships a 2.9 MB animated GIF as its og:image, and shopify.com a 2.7 MB PNG. Both stay inside Apple's 10 MB associated-resources budget, which is a generous allowance, and both are painful on a cellular connection. The real ceiling they test is the 1 MB main-resource limit, and there the sample split cleanly: wired.com, linear.app, figma.com, cloudflare.com, supabase.com and cal.com all crossed it. Figma and cal.com blew past the 1.6 MB ceiling our own fetcher applied, so their true page weight is larger than what we recorded. Two more pages sit right under the line — airbnb.com at 947 KB and theverge.com at 921 KB. Apple's client has to pull that HTML before it can lay out a single bubble.
Missing metadata turned up in three places. bbc.com/news, news.ycombinator.com and booking.com declared no og:image at all, so those links render exactly the gray bubble Apple documents as the default. Seventeen of the 34 pages that did set an og:title stuffed branding into it with a pipe or a dash — "Stripe | Financial Infrastructure to Grow Your Revenue", "WIRED - The Latest in Technology", "TechCrunch | Startup and Technology News" — while the technote asks for a short, specific title and the site name in og:site_name. Seventeen of 36 pages left og:site_name empty anyway. Twelve of 31 images declared og:image:width, and one of those declarations was fiction: supabase.com announces 800 and ships 1200.
Now the part of our first pass that was wrong, because it is the most useful thing here. nextjs.org/docs carries an og:image that reads ...&sig=... in the HTML source. Fetching that string literally returns 404. Decode the HTML entity behind the ampersand and the same URL returns 200 with image/png. Anyone pasting an og:image out of view-source into a tester hits this sooner or later, and the fix is to check for & before rewriting your route. The one genuinely dead image URL in the sample belongs to techcrunch.com: its og:image points at /wp-content/uploads/2018/04/tc-logo-2018-square-reverse2x.png, which returned 404 to both a GET and a HEAD request. The tag is present, correctly formed, and useless.
Why There Is No Re-Scrape Button
Facebook hands you the Sharing Debugger. X hands you the Card Validator. Apple hands you a technote, and that technote says nothing about caching. There is no dashboard showing what a recipient sees and no button that forces a refresh. The consequence is blunt: your preview gets judged once, on the device that receives it, and the sender never sees the verdict.
The one lever a sender holds is the URL itself. Preview state belongs to the URL, so a string the recipient's device has never seen gets fetched fresh — appending ?v=2 buys you that for the price of a slightly uglier link. Apple documents no such promise. It is simply the only move available when a card looks stale in an existing thread.
Apple's social-post branch deserves a mention because it is nearly untouched. The technote says previews of user posts need a twitter:card value of summary or summary_large_image plus a link element with type application/activity+json. Thirty of our 36 pages set a twitter:card. Zero carried the ActivityPub link element. Nobody has built that path yet, and for ordinary web pages it is irrelevant: not one page in the sample used twitter:image without also providing og:image, so Messages is reading Open Graph first.
iMessage Preview Checklist
- Ship an og:image at least 900 px wide, 1200–630 for comfort. The measured median page lands on 1200 wide, and the three failures all failed by hundreds of pixels, not by a hair.
- Stop at 300 KB. Bigger files still work, but two pages in the sample pay 2.7 MB and 2.9 MB for a preview thumbnail.
- Keep the page under 1 MB. Six of 36 blew this, and it is the one limit that can starve the whole preview before your image is ever considered.
- Put the tags in the server HTML. No JavaScript, no meta refresh. A meta refresh is invisible to the Messages client; a 301 is not.
- Check the image URL by fetching it. Decode HTML entities first. A tag that looks right in view-source can point at a 404, as techcrunch.com's does.
- Keep branding out of og:title, put it in og:site_name. Seventeen titles broke this and 17 pages skipped the tag that Apple names as the right home for it.
- Verify on a real device before the send matters. No debugger exists, so a test message to yourself is the only pre-flight check Apple gives you.
One Line
Apple's Messages rules are the strictest published set of Open Graph limits and the least tooled: a 900 px image floor, a 1 MB page ceiling, no JavaScript, no debugger. Thirty-one measured images cleared the floor, six measured pages missed the ceiling, and the failures were never exotic — thin logos, bloated client-rendered pages, one dead URL.
Paste your URL into the free OG checker to see the exact tags a scraper reads, then build the card itself at ogimgen.com — 1200×630, no text baked into the artwork, since the same file has to survive a phone and a Mac. Related reading: OG image size covers the dimensions every platform agrees on, the Signal and LINE guides cover two messaging apps that share Apple's gray-bubble problem, and Facebook's missing-image checklist shows what the same diagnosis looks like on a platform that does give you a debugger.