2 Oct 2026

Link Preview Privacy: What Your Private URLs Can Expose

Link preview privacy involves two separate questions: what a messaging service can read when it fetches a destination, and who receives the URL itself. A neutral preview can avoid exposing a message title or excerpt while still giving the fetching service a link that grants access. For private-by-link content, the address deserves as much care as the words behind it.This matters when a page is meant for a small audience: a personal note, a client draft, a private document, or a message that opens later. The sender may think the next person to visit will be the recipient. A preview fetch can happen first. A useful decision starts with the actual sharing channel and the destination's response, rather than the reassuring appearance of a closed envelope or a private chat.Official sources were checked on 2 October 2026. The technical example below uses synthetic data in local, in-memory request/response fixtures. It is not a test of Secret Letter or any live messaging platform.

Do link previews open a URL before the recipient clicks?

They can. In its documentation for classic link unfurling, Slack describes fetching a URL and looking for Open Graph or card metadata to build a preview. That is a real request to the destination, even though the person reading the conversation has not deliberately opened the page.Avoid turning that example into a claim about every chat app. Preview generation may happen on a sender's device, through a provider, through a connected integration, or under platform-specific settings. Those paths have different privacy consequences. Check the channel you actually use; its encryption label alone does not explain the entire preview workflow.Automated visits also have other causes. Microsoft's Safe Links documentation describes URL scanning and, in configured email flows, rewriting and time-of-click checks. A security scanner and a preview generator serve different purposes. Both explain why a URL may be processed by infrastructure beyond the intended reader. An early request in a log is therefore not reliable proof that a human has read the message.

What can a private link preview expose?

A preview card can reveal a name, a document subject, a thumbnail, or an excerpt. The destination may publish those fields in its HTML even when the visible page is locked. The Open Graph protocol defines fields including a title, description, image, and canonical object URL. Each field is another place where a developer can accidentally reuse private content.A birthday surprise with a generic title might be harmless. A sealed note with an excerpt naming a relationship problem is a different situation: the card can disclose the subject without revealing the whole note. Decide what the preview is allowed to say independently of what the final page will eventually display.Then consider the second channel of exposure. A fetcher must receive a usable address to request the page. If possession of that address is the access credential, the request transfers something valuable even when every preview field is generic. This is why hiding an excerpt and protecting a capability-bearing URL are different tasks.

What does a small metadata experiment show?

Our local fixture creates two HTML responses for the same fake private address. Both visible bodies say “Sealed.” One response puts the synthetic marker DEMO_PRIVATE_TEXT_9c2e in its Open Graph description. The other uses “A private message is waiting.” A simple metadata extractor can read the marker in the first response without running JavaScript or opening any envelope animation.

const secret = "DEMO_PRIVATE_TEXT_9c2e";
const personalized =
  '<meta property="og:description" content="' + secret + '">';
const generic =
  '<meta property="og:description" content="A private message is waiting.">';

personalized.includes(secret);
generic.includes(secret);

The expressions return true and false respectively. In the complete fixture, the request handler also receives the full fake path, /message/demo-capability-7f3a, in both cases. Changing the description removes the content disclosure from this response; it does not remove the address from the request that obtained it.These are deliberately constructed examples, not discovered product vulnerabilities. They demonstrate two boundaries that can be inspected independently. They do not measure a chat provider's storage, fetch timing, image caching, or later access. A production assessment needs authorized tests of those actual systems.

Which preview model fits your content?

Compare the disclosure and usability tradeoffs before enabling rich cards.
Model	Useful for	Remaining limitation
Personalized public card	Published articles and public releases	Title, excerpt, and image are intentionally disclosed
Generic private-page card	Low-risk messages where context should stay hidden	The fetcher still receives the destination URL
Authenticated preview	Account-based team content with a supported integration	The integration and card audience need their own permission review
Plain link with previews disabled	Sharing when a rich card adds little value	The channel still handles the URL; scanners may work separately

Rich previews reduce uncertainty for the reader. They can show that a link is a document rather than a download and help people recognize the destination. Generic cards sacrifice some of that context to avoid disclosing the subject. Neither model wins universally: public content benefits from informative cards, while private content needs a more deliberate boundary.

How does this apply to a future-reveal letter?

Secret Letter is a useful example of why the URL matters. Its current basic text experience is free, requires no account or recipient email, and creates the link immediately. The letter remains closed until the selected reveal date. It does not automatically email the message later, so someone must safely save or share the link.Its published privacy limits describe a private-by-link model, without a promise of end-to-end encryption. Anyone who obtains the URL may be able to read the message after reveal. Do not use it for passwords, financial information, medical records, or critical secrets. A date lock changes availability; it does not identify who possesses a forwarded address.Nothing in our fixture establishes what Secret Letter returns to a real preview bot. The relevant lesson is a handling decision: before pasting a future-reveal URL, consider whether the channel may process it automatically and whether that fits the message's sensitivity. Our existing Secret Letter review covers the product decision and its limitations. This article focuses on what can happen at the sharing boundary.

Does disabling or removing a preview undo the exposure?

Do not assume it does. A setting that stops preview generation before sharing may prevent that particular fetch. Removing a card after it appears is a later action: it cannot prove that no request occurred or that all copies of the metadata were deleted. The platform's documented behavior and retention rules determine what remains.There is also a difference between suppressing a visible preview and disabling all automated URL handling. Security checks may remain active. A plain-looking message can still contain a usable private address, and every member of a group conversation can potentially forward it. Pick the intended audience before adjusting the card.

What should developers inspect beyond the visible card?

Inspect the response that an unauthenticated request actually receives. Check page titles, Open Graph and social-card fields, structured data, image URLs, and serialized application state. A generic description is little help if a private excerpt remains in another metadata field. Preview images need special attention because their addresses may lead to separately accessible resources.Use synthetic content on a destination you control. Inspect the generated HTML locally first, then perform any authorized channel-specific checks with disposable links. Record what you observed and what you could not see. Sending a real private URL to a public preview debugger gives another service the address you were trying to protect.Review referrers as a separate browser behavior. MDN's Referrer-Policy reference explains that no-referrer omits referrer information, while the default strict-origin-when-cross-origin policy still sends a full referrer on same-origin requests. A referrer policy can limit that channel; it cannot hide the requested URL from the destination or a service deliberately fetching it.Keep private paths out of analytics payloads and error reports. Serve generic metadata to requests without permission, and withhold protected text from the entire response. The companion client-side versus server-side access-control article demonstrates why a closed interface alone cannot provide that protection.

What is worth checking before sharing a private URL?

Ask three concrete questions: who can see the conversation, what automated services may process the link, and what the destination returns without identifying a recipient. If the content would cause harm outside that audience, a more restrictive access model may be necessary. Changing the preview does not change the underlying sharing permission.For a low-risk personal message, a carefully stored private link can be a reasonable convenience. Keep the URL intact, choose a suitable channel, and avoid unnecessary forwarding or shortening services. For a link with timing requirements, our link-lifecycle comparison separates reveal dates from expiration. More app and architecture decisions are covered in the Tools category.