When an article introduces another page, the link can be shown as plain text or as a card with a title, short description, URL, and sometimes an image. These are often called blog cards, link cards, or link previews.
Images can make a card easier to notice, but they are not always the right default. The practical tradeoff depends on whether the image is fetched automatically, set manually in the article, or omitted when it is not needed.
How many blog sites handle it
Many blog platforms and CMSs generate a card when you paste a URL. They fetch the link title, description, and Open Graph image, then show a preview in the editor or published article.
That does not always mean the page is fetched every time a reader opens the article. In many systems, the result is saved at paste time, publish time, or in a service-side cache. If the destination page changes its OGP image later, the card in the article may not update immediately.
- A pasted URL can be expanded into a card automatically
- The fetched result may be stored in article data or a cache
- If an image cannot be fetched, the card can fall back to title, description, and domain
- Some platforms do not allow much control over the card design
- Internal links may use richer cards while external links use simpler cards
What image cards do well
A card with an image can help readers understand the destination before they click. This is useful for apps, products, services, events, and visual articles where an icon or Open Graph image gives useful context.
Images also help separate multiple cards in the same article. When several external links appear close together, visual differences can make the list easier to scan than a group of plain text links.
What makes image cards harder
External images introduce failure cases. The image may be blocked, missing, cropped poorly, replaced later, or heavy enough to affect loading. A card UI also has to decide what to do when the image is unavailable.
- External images may fail because of hotlink protection or fetch restrictions
- The OGP image ratio may not match the card layout
- A changed image on the destination site can unexpectedly change the article
- Many image cards can affect performance and layout stability
- App icons and logos may require checking usage terms before display
Manual images are less flashy but more stable
For smaller sites or editorial sites that want control, a manual image field can be a good compromise. It adds some editing work, but the article owner can choose the image, crop, and description instead of depending on whatever the destination page exposes.
Text-only cards are also valid. For documentation-heavy sites, technical notes, and verification reports, a title, short description, and domain can provide enough context without adding visual noise.
A practical default for TOOLPOOL
For a site like TOOLPOOL, where many articles are notes, checks, and tool explanations, text-first cards are a practical default. Readers can still see what the link is and why it appears in the article.
If images are added later, they should be optional rather than required for every card. App introductions, service notes, and product pages are good candidates; simple documentation links often do not need an image.
A sensible implementation path
- Start with title, description, and domain
- Add image as an optional field
- Design the no-image state first
- Only add automatic fetching after caching and failure handling are clear
- Check terms before using app icons or service logos
A blog card is not just decoration. It helps readers understand where a link goes and why it belongs in the article. Whether it needs an image should be decided from that purpose, not from visual richness alone.