Choosing the tool

When to use this

Maintained by the MAIN OÜ engineering team · Last reviewed 18 August 2026 · Verified against the shipped implementation

A self-destructing link solves one narrow problem: getting a secret from one person to another without leaving a permanent copy in a chat log or an inbox. It is a poor substitute for most other things. This page is about telling the two apart.

The short version

Three handoffs, worked through

Passing a temporary credential to a contractor

A contractor starts Monday and needs the staging database password until their own account is provisioned. This is close to the ideal case: short-lived, single recipient, and the value expires by design.

Set a password on the share. Send the link by email and read the password aloud on the call where you brief them. Set the TTL to match the call, not the week. When they confirm, rotate the credential on the schedule you already planned, because the point of a temporary credential is that it stops working, not that it was delivered carefully.

Sending a signed contract to a client's finance team

Workable, with one caveat that decides it. A single named recipient who is expecting the document is fine. A shared finance@ mailbox is not, because the first person to open the link consumes it and everyone else sees an error.

For a group, send it to one named person and let them distribute internally, or use a service built for multi-party access. One-time delivery and shared inboxes are structurally incompatible.

Sending a photo of an identity document

Common, and the reason to think about it is not the transport. Encryption in transit is the easy part. The questions that matter are whether the recipient genuinely needs the document, what they will do with the copy they now hold, and how long they will keep it.

A one-time link keeps the image out of your sent folder and their inbox, which is a real improvement over an attachment. It does nothing about the copy they save to their desktop. If the recipient is a business processing your data, the minimisation principle in GDPR Article 5(1)(c) generally expects them to hold no more than their stated purpose needs. What that requires in a specific case turns on their role and legal basis, but asking how long they intend to keep it is a reasonable question.

The constraints that usually decide it

Most of the time the answer falls out of one of four practical limits rather than any security argument.

• 24 hours, maximum. The TTL ceiling is deliberate. If the recipient might not look until next week, this is the wrong mechanism and no setting will fix it.
• One reader, once. Not one team. Not one mailing list. Not a link in a ticket that three people will click.
• 10 MB per file by default, set per plan. Enough for documents and photographs, not for video or archives. Sending files at all requires a signed-in account with a verified email address; notes do not.
• No recovery, ever. We hold no key. If this is the only copy of something, do not send it this way.

Use something else when

The secret is long-lived

Shared team credentials belong in a password manager with access control and revocation. A one-time link that delivers a permanent password just moves the problem into whatever the recipient does next, which is usually paste it into a note.

You need proof of delivery

We record that a share was opened, not who opened it, because identifying readers would mean collecting exactly the data the design avoids. If you need an attributable audit trail, use a document service built for it.

The recipient's device is the actual risk

If the concern is that the recipient's machine may be compromised, changing how the secret arrives does not help. It arrives on the compromised machine either way.

It has to be read exactly once

Delete-on-read is best-effort rather than transactional, and an automated scanner can be the first reader. If a second read would be a serious incident rather than an inconvenience, this is not the right guarantee. The security page explains why in detail.