What Are Microbrowsers and How Do They Affect Link Previews?
Microbrowsers fetch shared URLs to build link previews. Learn how platforms use page metadata, why previews differ, and how to debug yours.
A microbrowser is a lightweight platform-side client or fetcher that visits a URL shared in a message and helps create a link preview. The term is useful shorthand, but platforms generally describe the feature as a link preview, unfurl, bot, or embed rather than as a standardized product class. The fetcher requests the page, reads available information such as Open Graph metadata, and the messaging service renders a card. Each platform controls its own fetching and display behavior, so the same page can produce different previews in Slack, Discord, and Apple Messages.
How link previews work
- Someone shares a URL. Use a fully qualified address, including
https://. Slack specifically requires the protocol for classic unfurling. - The platform fetches the page. The platform’s service requests the URL and may retrieve referenced preview assets such as an image. Discord says its fetch is triggered when a link is shared in a message, not by continuous crawling of all sites.
- The platform selects preview information. It may inspect Open Graph tags and other metadata. The Open Graph protocol defines properties including
og:title,og:type,og:image, andog:url. - The app renders a card. A card may show a title, description, image, or platform-specific media. The service decides which fields to use, how to lay them out, and whether to use cached information.
Metadata provides suggestions; it does not guarantee that every application will show every field or update at the same time. Slack describes its default behavior as classic link unfurling, which checks common Open Graph and X Card metadata. Apple’s developer guidance recommends Open Graph metadata for Messages rich previews, with additional page setup guidance.
Why platforms show different previews
| Platform | Documented behavior | What to check |
|---|---|---|
| Slack | Classic unfurling crawls links and checks common Open Graph and X Card metadata. An installed Slack app can also handle a link_shared event and supply custom content using chat.unfurl. |
Check page metadata, whether a Slack app provides a custom unfurl, and the permissions and configuration for that app. |
| Discord | Discordbot visits a shared URL to retrieve details such as title, description, and image. Discord may temporarily save linked image or video content and serve a copy. | Check that the page and its assets are fetchable. A request in your logs may be a preview fetch; a viewer may get cached media from Discord rather than directly from your media host. |
| Apple Messages | Apple’s developer technote recommends Open Graph metadata for rich previews and gives Messages-specific page setup guidance. | Follow Apple’s current guidance for Messages. Do not assume that tags alone guarantee a matching result on every platform. |
For Slack messages posted through the API, unfurl_links and unfurl_media are separate controls. Slack says setting both to false prevents crawling and attempted unfurling for that posted message. These are Slack API settings, not general HTML controls. For a Slack app’s custom unfurl, the documented scopes include links:read and links:write; grant only the access the app needs.
Set up metadata for your own site
Add accurate, page-specific metadata in the document head. Use absolute URLs for the page and image so a platform can resolve them without guessing.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>A useful page title</title>
<meta name="description" content="A concise, accurate description of this page.">
<meta property="og:title" content="A useful page title">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/guides/page">
<meta property="og:image" content="https://example.com/images/page-preview.jpg">
<meta property="og:description" content="A concise, accurate description of this page.">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="A useful page title">
<meta name="twitter:description" content="A concise, accurate description of this page.">
<meta name="twitter:image" content="https://example.com/images/page-preview.jpg">
</head>
<body>
<main><h1>A useful page title</h1></main>
</body>
</html>
This is a starting point, not a guarantee of identical output. Check the Open Graph protocol’s requirements and image guidance, and Apple’s current Messages guidance if you are targeting that app. Keep the title and description specific to the actual page. The shared URL should be the intended canonical page, and both the page and preview image must be reachable by the fetching service.
Test and debug a link preview
- Copy the exact URL that will be shared. Include
https://, and check redirects, trailing slashes, and whether the destination requires a session or special headers. - Inspect the served HTML. Confirm the Open Graph tags are present in the response’s document head, not only inserted later by client-side JavaScript. Fetching behavior differs, so server-rendering the metadata makes it available in the initial HTML.
- Verify the image URL separately. It should be absolute and return the intended image to a service that does not have your browser cookies. Check for access restrictions, broken redirects, and a wrong content type.
- Share the URL in the target platform. Test Slack, Discord, or Messages directly. A result in one platform does not prove another will select the same metadata or refresh its preview at the same time.
- Check logs and app behavior. Look for a platform fetch or a custom Slack app handling the shared link. When diagnosing access, remember that user-agent strings can be spoofed.
- Recheck current platform guidance. Bot identification details and network ranges can change. For firewall rules, Discord recommends checking requests against its official public IP ranges as well as considering its example user-agent; do not rely on a user-agent alone.
Common problems and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| No preview appears | The URL is not fully qualified, the page cannot be fetched, or the platform has no usable metadata. | Share an https:// URL, make the page publicly reachable by the platform fetcher, and add page-specific Open Graph fields. |
| Wrong title, description, or image | Metadata is missing, stale, inaccurate, or different from what the platform selects. | Inspect the initial HTML for the exact shared URL, correct the relevant tags, and test again in the platform that matters. |
| Image is missing while text appears | The image URL may be relative, blocked, redirected unexpectedly, or inaccessible without a browser session. | Use an absolute, publicly fetchable image URL and check its response and redirects independently. |
| It works in one app but not another | Platforms use different metadata selection, fetching, cache, and rendering behavior. | Test each intended platform and follow its own documentation. Do not treat one successful preview as a cross-platform compatibility test. |
| Slack shows custom content | An installed app may handle the link_shared event and call chat.unfurl. |
Review the app’s configuration, scopes, and handler before changing site metadata. |
| Firewall blocks a preview fetch | Access rules may block platform requests or identify bots using a spoofable user-agent. | Use the platform’s current official identification guidance. For Discord, verify against its current published IP ranges rather than trusting the user-agent alone. |
Privacy and security implications
Sharing a URL can cause a platform service to request it, which may create a request in your site logs. Discord says its link fetch happens when a link is shared, rather than as continuous website scanning. Treat shared links as potentially visible to the platform that processes them, and make sure access controls are designed for automated requests as well as ordinary browsers.
Discord says it may temporarily save a linked image or video and later serve that copy from Discord. That can keep the viewer’s IP address private from the original media host for that delivery, but it should not be generalized to other platforms or to the initial page request.
A preview card is not a safety certification. A 2020 NDSS security study tested 20 social and messaging platforms and found that, under its test conditions, four could create benign-looking previews for malicious resources. This is a historical result from a bounded study, not a current measurement of all platforms. Inspect the actual destination domain instead of treating a familiar-looking card as proof that a link is safe.
A separate research paper archived by the U.S. National Science Foundation describes an unfurl-related Slack confidentiality attack in the configuration it studied. Use that research as a reason to review app permissions carefully, not as evidence that every Slack unfurl exposes private messages or that the studied issue persists unchanged.
Or skip the browser setup
If your goal is to inspect how a page renders before sharing it, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns an image or PDF; the API and its options are documented at ScreenshotNeo documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp
Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets. Those cleanup steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which page verdict and billing status applied. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up free for 1,000 screenshots a month, with no card.
Performance, reliability, and cost notes
- Preview generation is outside your page’s control. The platform fetches and renders the card, and platforms may cache information or assets. Do not promise readers an immediate refresh after changing tags.
- Keep the metadata response efficient. Return useful metadata in the initial HTML and keep referenced assets reachable. A page that depends on a logged-in browser session or delayed client-side rendering is harder for a separate fetcher to interpret.
- Account for fetch traffic. A shared URL can generate requests to your page and preview assets. Monitor logs and size access controls to account for platform fetchers.
- There is no universal preview cost figure. Costs and request behavior depend on the platform and your hosting setup; the reviewed platform guidance does not establish a single rate or cache lifetime.
Frequently asked questions
Is “microbrowser” an official platform term?
It is a useful descriptive label, but the platform documentation reviewed here uses terms such as bot, unfurl, embed, and link preview.
Can I force every platform to show the same card?
No. You can provide clear metadata and follow each platform’s guidance, but each service controls how it fetches and renders a preview.
Does a preview prove that a link is safe?
No. Preview appearance is not a security check. Verify the destination domain before opening a link.
Can a Slack app replace the default preview?
Slack supports app-provided unfurls through its link-sharing event and unfurl API, subject to the app’s configuration and permissions.


