A link shared in LINE shows a blank card, or last month's image. The app gives you zero hints about why. The fix is usually one of two things: an og:image served over plain HTTP, or a stale cache that LINE never tells you how to clear. LINE's servers crawl your URL and build the preview card, but there's no spec, no debugger, and no published cache schedule.
That opacity is the whole problem. Discord has a visible unfurl, Facebook has a Sharing Debugger, Telegram has Instant View — LINE has none of it. You fix your tags, every other platform renders the new card, and LINE keeps showing the old one. Most people assume the fix failed. It didn't — the cache just hasn't moved yet.
Here's what I'll cover: why LINE previews fail, the handful of rules that actually matter, and a fix sequence that works without any official tool. Every tag check below is reproducible with ogimgen's free OG checker.
Why LINE Shows the Wrong Image or No Image
LINE's servers fetch your page's Open Graph tags when a link is sent — in regular chats and LINE Official Account messages alike — then attach a card with the image, title, and description. The fetch happens on LINE's side, not on the reader's phone the way Signal does it, which is why LINE tolerates slower pages. What it does not tolerate:
- An og:image served over HTTP. LINE drops http:// image URLs. If the page or the image isn't on HTTPS, the card renders without a thumbnail. It's the fix that shows up over and over in LINE developer community threads about blank cards.
- No og:image tag. The card shows title and description only. LINE doesn't scrape the page hunting for a fallback image.
- A stale cache. LINE caches metadata per URL and refreshes on its own schedule, which it has never published. You fix the tags, and LINE keeps serving the old card for days. This is the number one cause of "I fixed it but LINE still shows the old image."
- Duplicate or malformed og tags. The first og:image LINE encounters wins. One broken tag early in the head can kill the card even when a valid one sits further down.
- An image URL that isn't publicly fetchable. 404s, hotlink protection, and signed URLs with short expiry all fail the fetch silently.
- Edge rules blocking LINE's fetcher. CDN bot management or security plugins that challenge unknown user-agents stop the crawl before it reads a single tag.
The first, third, and fifth items are the ones that catch people off guard. HTTP images are the classic silent killer — your preview works in a local preview tool that doesn't enforce HTTPS, then fails in LINE. The stale cache is the one that looks like a bug but isn't.
The OG Specs LINE Actually Uses
LINE never published a formal spec for link previews — no pixel minimum, no file cap, no documentation page. The rules below come from what the app demonstrably does when it fetches a URL, plus the constraints LINE's developer community has confirmed over the years:
| Setting | LINE's Behavior | What Breaks |
|---|---|---|
| HTTPS | Required for the page and the image | http:// og:image URLs are dropped |
| Dimensions | No published minimum; 1200×630 works | Very small images render soft in the card |
| Format | PNG or JPEG | Nothing, as long as the file loads fast |
| File size | No published cap; keep it under 1 MB | Heavy files slow the fetch from LINE's servers |
| Debugger | None | No way to force a re-scrape |
| Cache | Server-side, expiry unpublished | Stale cards persist after tag fixes |
| Crawler | LINE's servers fetch on send | Edge rules that challenge unknown bots |
In practice, the spec that bites is HTTPS, and the behavior that confuses is the cache. A 1200×630 PNG under 1 MB served over HTTPS satisfies LINE completely — no platform-specific size is needed the way Pinterest demands a 600 px minimum.
Real talk: LINE's preview card is a compact thumbnail beside the title and description, and the audience is overwhelmingly mobile — the app dominates Japan, Taiwan, and Thailand. Text in the middle of your image survives the crop; text pinned to the right edge can end up under the card's text column. Keep the headline centered.
How to Fix a LINE Link Preview (Step by Step)
Because LINE has no debugger, the workflow is: verify, test, and if it's a cache problem, force a new URL. This is the sequence I run:
- Verify the tags. Paste your URL into the OG checker. Confirm og:image exists, serves over HTTPS, and reports valid dimensions. If the checker flags a broken image, LINE will too.
- Confirm the image loads publicly. Open the og:image URL in an incognito window. You want a direct 200 with no redirect chain. LINE's fetcher won't follow login walls, geo-blocks, or signed URLs that expire in an hour.
- Test in the composer before you send. Paste the URL into any LINE chat's input box. The preview card renders above the input immediately, so you see exactly what recipients would get — and you can dismiss the card before hitting send. Testing costs nobody a message.
- Fix the tags, then cache-bust. After deploying the fix, share the URL with a query string appended — ?v=2, ?utm_source=line, or a hash. LINE treats the new string as a new URL and fetches fresh metadata. This is the only way to force LINE's cache, because no re-scrape endpoint exists.
- Wait out the original URL. Keep sharing the clean URL in real posts and re-test it weekly. Community reports put the refresh anywhere from a few days to a few weeks — LINE publishes no schedule, so treat the refresh as eventual, not guaranteed.
- Check edge rules last. If the card still fails after all of this, confirm your CDN doesn't challenge unknown bot user-agents and that hotlink protection is off for image paths.
Step 4 is the counterintuitive one. On Facebook you scrape with the Sharing Debugger; on X you re-validate the card. LINE gives you neither, so the only lever you control is the URL itself. A query string is invisible to your readers and changes nothing about your page — it just makes LINE treat the link as new.
LINE vs. Telegram vs. WhatsApp: Preview Behavior Compared
LINE, Telegram, and WhatsApp all fetch previews server-side, which puts them in a different family from Signal's on-device model. Within that family the differences are about tooling, not tags:
| Aspect | LINE | Telegram | |
|---|---|---|---|
| Preview fetch | Server-side | Server-side | Server-side |
| Official debugger | None | Instant View (t.me/iv?url=) | None |
| Cache control | None — cache-bust with query strings | Re-fetch via Instant View | None — cache-bust with query strings |
| Core market | Japan, Taiwan, Thailand | Global | Global |
| Typical failure | Stale cached card | Blocked bot or bad tags | Blocked crawler |
Telegram is the only one of the three with any official tooling — Instant View can show you what Telegram's fetcher reads, which makes it a partial debugger. WhatsApp is as opaque as LINE, but its failure mode is usually a blocked crawler rather than a stale cache. LINE's distinguishing feature is the regional audience: a card that fails here doesn't fail in a small niche, it fails in front of the primary messaging app of three countries. The Telegram guide in this series covers the server-side model with a debugger; the Signal guide covers the opposite architecture, where the reader's phone does the fetching.
Summary
LINE link previews fail for the standard reasons — missing tags, unreachable images, blocked fetches — plus one LINE-specific trap: a cache you can't see, purge, or schedule. The fix workflow is short once you accept the platform: verify your tags with an OG checker, confirm the image is HTTPS and publicly loadable, test the card in the composer before sending, and cache-bust with a query string when the card is stale.
Generate a 1200×630 card with ogimgen in about 30 seconds and check it with the OG checker. If you publish for a Japanese, Taiwanese, or Thai audience, this is the preview that represents your link in their default chat app — worth the ten minutes to get right.