Skip to content
SecretPNG

Why One-Time Links Can Be Opened by Security Scanners

Corporate email filters and chat apps often visit links before you do. Here is why that can consume a one-time secret link, and how to share secrets anyway.

By SecretPNG TeamReviewed by SecretPNG Security TeamPublished 2026-07-14Updated 2026-07-14

You send a colleague a one-time secret link. Minutes later they tell you it says the secret has already been viewed, even though they swear they never clicked it. Nobody is lying, and usually nothing was hacked. In most cases, a machine opened the link first.

Modern email security gateways, chat platforms, and collaboration tools routinely fetch URLs in messages, either to scan the destination for phishing and malware or to build a visual preview card. To a server hosting a one-time secret, that automated visit can look exactly like the recipient arriving, and a strictly one-time secret gets consumed.

What the scanner actually sees

With SecretPNG's secret links, an important detail limits the damage. The secret is encrypted in your browser with a random 256-bit AES-GCM key, and that key is carried only in the URL fragment, the portion after the # symbol. Under the URI standard, browsers do not send the fragment to servers, and many scanning systems process only the server-visible part of the URL.

The server itself stores only ciphertext and the expiry and view rules, so a scanner that merely triggers the one-time retrieval endpoint consumes the ciphertext's availability without necessarily obtaining the decryption key. Even so, you should treat a consumed link as potentially exposed: some scanners execute pages in full browsers, fragment included, and behave like a real visitor.

How to share secrets in scanner-heavy environments

You can work with this reality rather than against it. A few adjustments make one-time sharing dependable even when automation sits between you and the recipient.

  • Allow a small number of views, or use a short time-based expiry instead of a strict single view, when sending into a corporate mailbox.
  • Send the link through a channel that does not generate previews, or disable the preview before sending if your app allows it.
  • Tell the recipient the link is coming and ask them to open it promptly, then confirm they saw the secret.
  • If the link is consumed before the recipient saw it, rotate the secret and send a fresh one rather than debating what happened.

Atomic retrieval, honest expectations

SecretPNG's one-time retrieval is atomic: exactly one request can ever succeed, so a secret can never be silently delivered twice, even if two visitors race each other. That guarantee is about the server's behavior, not the world's. After a legitimate view, the recipient can copy or screenshot what they saw, and no expiry setting changes that.

One-time links remain one of the most practical tools for sharing secrets, precisely because a burned link is loud. When a link is consumed unexpectedly, you know something visited it and you can respond by rotating the secret, which is a far better failure mode than a password sitting quietly in an inbox for years.

Limitations to keep in mind

  • There is no reliable way to distinguish an automated scanner from a human visitor, so a consumed link should always be treated as potentially exposed.
  • Some scanners execute pages in a full browser environment and may process the URL fragment like a real visitor would.
  • Multi-view or time-based expiry settings reduce scanner problems but widen the window in which an unintended party could use the link.

Sources