A blank link card on Threads is not a styling problem. Threads never renders your page. Meta's crawler fetches your HTML once, reads the Open Graph tags out of it, caches what it found, and Threads draws the card from that cache. Break any link in that chain and you get a bare URL sitting in the post with no way to see what went wrong.
So we took the crawler's side of the table. On November 4, 2026 we fetched 76 homepages exactly the way facebookexternalhit fetches them — the same user agent string Meta publishes for link shares — then pulled every og:image we found and measured the pixels. Sixty-eight pages came back readable. The other eight told us something more useful than a card would have.
There Is No Threads Debugger, And That Is The First Problem
Facebook has the Sharing Debugger. Threads has nothing. Every guide that tells you to "run your URL through the debugger and see what Meta sees" is silently borrowing Facebook's tool and hoping it maps onto Threads.
It maps at the crawler level, and only at the crawler level. We went looking for a Threads-side scrape endpoint the way Bluesky hands you one. What we found: developers.facebook.com/tools/debug/echo/?q=<url> answers 302 into business.facebook.com/business/loginpage, and the plain Graph scrape call without a token returns {"error":{"message":"(#2) Service temporarily unavailable","code":2}}. Both routes want a login or an app token. There is no anonymous "show me the card" call for Threads.
Meta's own documentation says the crawler exists to fetch "the content of an app or website that was shared on one of Meta's family of apps, such as Facebook, Instagram, or Messenger." Threads belongs to that family and publishes no crawler of its own, so the practical model is: your HTML gets fetched by that user agent, once, cached, and reused. Test against the crawler, not against the app.
Seventy-Six URLs, Fetched As The Crawler
Method, so you can repeat it. One request per URL with the published crawler UA string, no JavaScript, HTML parsed with a plain streaming parser, and every og:image URL then fetched separately and measured from its own bytes rather than from the declared og:image:width.
| Measured | Result | What it does to the card |
|---|---|---|
| Pages readable by the crawler | 68 of 76 | Eight refused it outright with a 403 |
| og:image present | 59 of 68 (87%) | Nine pages have nothing to draw |
| og:title present | 61 of 68 | Median length 43 characters |
| og:description present | 60 of 68 | Median 130 characters, longest 267 |
| og:type declared | 53 of 68 | Missing on 15, mostly fine in practice |
| og:url declared | 51 of 68 | Cards still render without it |
| No Open Graph block at all | 6 of 68 | Text-only card, every time |
| og:image fetched and measured | 54 of 59 | Median 1200 × 630, which is right where it should be |
| Image under 200px wide | 1 (192 × 192) | Below Meta's documented floor, so it gets dropped |
| Image under 600px wide | 5 of 54 | Card renders, image is thumbnail-sized |
| PNG / JPEG / WebP / SVG | 35 / 15 / 2 / 2 | The last four formats are the risky ones |
| Aspect ratio within 1.85–1.95 | 33 of 54 | The rest get cropped or letterboxed |
| gzip or deflate served to the crawler | 62 of 68 | Six send raw bytes, which Meta says it cannot accept |
Honors a Range request | 29 of 68 | None of the 29 cut the tags off, so this one is theory, not a real-world kill |
| Time to first byte plus transfer | median 2.6s, worst 5.4s | Ten pages crossed four seconds |
Real talk on that last row. Meta's crawler guidance says the content has to be crawlable "within a few seconds" and that Open Graph properties must sit before the first megabyte. We checked the second claim directly by finding the byte offset of og:image in each response: median offset was 3 KB, the worst page put it at 163 KB (hubspot.com, after a wall of inline styles). Nobody in our sample came close to the megabyte ceiling. The rule is real and almost nobody trips it.
The Four Ways A Threads Card Dies
Your server refuses the crawler. Eight pages in our sample answered the crawler with 403. Wikipedia's Open Graph article is the cleanest example: 200 with a normal browser user agent, 403 the moment the request carried the crawler string. The same eight pages mostly refuse everyone — Medium, Patreon, Canva, Adobe, The Atlantic, Product Hunt and Indie Hackers all block us regardless of UA — but Wikipedia's case is the one to remember, because a Cloudflare or WAF rule that only fires on crawler user agents is invisible when you test in a browser.
Worth noting the inverse too: reddit.com and nytimes.com returned 403 to our browser string and 200 to the crawler. Blocking bots and blocking that bot are two different configurations, and only one of them breaks your preview.
No og:image ships. Nine usable pages had nothing. Six of them had no Open Graph block at all: theguardian.com/international, news.ycombinator.com, developer.mozilla.org, microsoft.com, dropbox.com, trello.com. That is not an indictment of their engineering — several render metadata client-side and are fine in Facebook's own debugger. It is a reminder that a crawler which does not run JavaScript sees your source, and only your source.
The image is unreachable or the wrong format. Three of the 59 image URLs failed us outright. techcrunch.com's og:image is a 404 — a /wp-content/uploads asset from 2018 that no longer exists on the server that advertises it. clickup.com declares a relative path, /assets/brand/clickup-meta.png, which a crawler has no base to resolve cleanly; our fetch of it never completed. And two sites in the sample ship SVG as og:image. Meta's image requirements enumerate dimensions, file size and encoding but never list SVG, and the format needs a parser the card renderer does not advertise. Treat a vector og:image as a blank card until proven otherwise.
The image is too small. Meta publishes the floor: 200 × 200 pixels minimum, 8 MB maximum, 1200 × 630 for high-resolution displays, and at least 600 × 315 if you want the large card. Only one page in our 54 measured tripped the hard floor — reddit.com at 192 × 192 — but five sat under 600px wide, which is the quieter failure: the card appears, and the image looks like an afterthought. ogp.me ships 300 × 300. Substack 400 × 400. Ars Technica 512 × 512. Big companies, small cards.
Two Things Only Threads Does
The Threads API documentation states the rule plainly: if you include URLs in the post text, "the first URL in the text field will be used as the link preview for the post." One card per post, and it belongs to whichever link you typed first. Paste two and the second one is just blue text.
Threads also enforces a link budget. The docs cap links at five, counted as unique URLs across the text field plus a separate link_attachment if you supply one that does not appear in the text, and since December 22, 2025 posts above that limit fail during media creation with THREADS_API__LINK_LIMIT_EXCEEDED. The link_attachment parameter only works on text-only posts — attach an image and the API ignores it.
For anyone posting by hand rather than by API, the consequence is simple. Put the link you want carded at the front of the post, and do not stack three URLs expecting three cards. For anyone posting through the API, set link_attachment explicitly on text posts so the card cannot drift to a URL you added as an aside.
One more measured oddity, from Meta's own product: threads.com profile pages emit og:type twice, once as profile and once as article, and they declare twitter:card as summary rather than summary_large_image. Their og:image comes from cdninstagram.com. If Meta's own front door ships duplicate properties and a small-card declaration, your single tidy set of tags is not the thing holding you back.
We Ran The Same Crawler Test On Our Own Seven Sites
Then we pointed the script at our own domains, which is the part of this exercise that stings.
fastsudoku.com and tube2blog.com serve no og:image to the crawler at all — og:title, og:description, og:url, og:site_name, and then nothing. fastsudoku even advertises twitter:card as summary_large_image, which promises a large image it never delivers. geocheckr.com and socipub.com both hand out SVG files — og-image.svg at 1200 × 630 on one, logo.svg at 1024 × 1024 on the other — which runs into the format problem above.
And the one that produced this whole article: ogimgen.com's og:image points at /api/og?title=..., a route that generates the PNG on demand. It returned HTTP 500 to the crawler. It also returned 500 to a normal browser user agent, so this was not a bot filter — the render route itself was failing, and had been failing while we wrote about other people's broken tags. Three of seven domains, broken in three different ways, on a site whose entire subject is Open Graph images.
That is the argument for testing instead of reasoning. Nothing on our dashboards showed this. The pages rendered, the meta tags were present in source, the audit tools we normally run were happy with the tag list. Only fetching the image URL the way a crawler fetches it turned up the 500.
Fix Order That Actually Moves The Card
- Fetch your page as the crawler.
curl -sL -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" https://yourdomain.com | grep -o 'property="og:[a-z:_]*" content="[^"]*"'takes five seconds. A 403 here ends the investigation; nothing else you fix will matter. - Fetch your og:image URL with the same user agent and read the response code. A 200 with
image/pngin the content type is the pass. A 500 on an on-demand generator route is a real failure mode, so test the URL, not the tag. - Check the bytes, not the declaration. One page in our earlier audits declared 800 pixels wide and served 1200. Another advertised a 2.9 MB animated GIF. Read the real dimensions out of the file.
- Pre-cache before you publish. Meta documents that the crawler "has to see an image at least once before it can be rendered", meaning the first person to share your link may get the imageless version. Run the URL through the Sharing Debugger once after deploy — even though it is Facebook's tool — because the crawler it warms is the one Threads uses.
- Keep the tags in the first chunk of HTML. Serve gzip or deflate, keep og:image inside the opening kilobytes rather than after a megabyte of inlined CSS, and return the full head when a crawler sends a
Rangeheader. Our sample shows almost nobody fails this; it also shows six sites that fail the encoding requirement. - One link, at the front. The first URL in the post text owns the card. Do not bury it behind a second link and then wonder why the preview shows the wrong page.
One Line
Threads has no debugger, so the only honest way to know what your card will look like is to fetch your own page with Meta's crawler user agent, then fetch the og:image URL the same way and measure what comes back. Sixty-eight readable pages out of 76 gave us a clear picture: the tags are usually there, and the failures cluster in three places — a WAF that refuses the crawler, an image URL that 404s or 500s, and formats the renderer never claimed to support. Our own seven domains produced all three.
Paste your URL into the free OG checker to see the properties your server HTML actually exposes, and build a correct 1200 × 630 PNG at ogimgen.com if yours is missing or the wrong shape. Related: the Bluesky card-service breakdown shows what a preview looks like when the platform hands you a public endpoint, the OG image size guide covers the 200px floor and the safe zones, and the Facebook preview troubleshooting guide walks the Sharing Debugger path in detail.