Feature

Self-Destructing Notes: Expiry, View Limits and Their Limits

A self-destructing note stops being available once a condition you set is met — a deadline, a view count, or both. It is one of the most useful things you can do to reduce risk, and one of the most commonly misunderstood.

Last reviewed July 31, 2026Reviewed by Inkrypt Security Team

The short answer

A self-destructing note stops being available once a condition you set is met — a deadline, a view count, or both. It exists because most sensitive text is dangerous not at the moment it is sent but for years afterwards, sitting in a searchable history. Expiry makes a dead link the default outcome rather than one that still works long after the secret stopped being needed.

The problem expiry solves

Most sensitive text is dangerous not at the moment it is sent but for years afterwards. A database password pasted into a chat in 2023 is still sitting in that chat's searchable history today. When the workspace is eventually breached, or an ex-employee's account is compromised, or the vendor changes their retention policy, that message is still there and still valid.

This is the accumulation problem: every secret you share through a persistent channel adds permanently to your exposure. Expiry attacks it directly by making the default outcome a dead link rather than one that still works years later.

The two mechanisms

Time-based expiry

You set a lifetime. Once it elapses the link stops resolving to anything — the server refuses the request instead of returning the ciphertext. This is the right control when you know roughly when the secret stops being needed: a contractor needs access this week, a credential is being rotated on Friday.

View limits

You set a maximum number of retrievals. The server counts each time the encrypted payload is requested, and once the count reaches your limit the link stops serving it. A limit of one gives you classic burn-after-reading behaviour.

View limits have a second, underrated property: they are a tripwire. If you set a limit of one and the recipient tells you the link is already dead, that is evidence someone else opened it. You have learned something you would never have learned from an email.

Counting happens server-side

The count increments when the ciphertext is fetched, which is the only event our servers can observe. We cannot know whether the fetch was followed by a successful decryption, because decryption happens in the browser with a password we do not have.

What expiry cannot do

This deserves to be stated bluntly, because a great deal of marketing around self-destructing messages implies otherwise.

It cannot un-read a note. Once plaintext is on a recipient's screen, it is in their control. Screenshots, copy-paste, a photo of the monitor, or simply remembering it are all outside any technical boundary we have.
It cannot control a forwarded secret. If the recipient pastes the credential into their own notes app, your expiry setting is irrelevant to that copy.
It cannot prevent automated preflight. Some corporate mail filters, chat clients and security scanners fetch URLs automatically to check them. A view-limited link can be consumed by a scanner before the human ever clicks it. This is the single most common cause of 'the link was dead when I opened it'.
It cannot retroactively protect a secret already exposed. If the note was intercepted while live, expiry afterwards changes nothing.

Design around scanners

If you are sending a one-view link into an environment with mail filtering or link-preview bots, expect it to be consumed in transit. Prefer a short time-based expiry with a view limit of two or three, and confirm receipt out of band.

Choosing the right setting

Practical defaults. When in doubt, shorter and stricter, then re-send if needed.
Scenario	Suggested expiry	Suggested view limit
Credential handed to a colleague you are talking to now	1 hour	1
Credential emailed to someone in another timezone	24 hours	2–3 (allows for scanners)
Onboarding details for a new contractor	7 days	3–5
Note to your future self	Longest you genuinely need	No limit
Anything you would describe as high-stakes	Shortest workable	1, plus confirm receipt by phone

Practical defaults. When in doubt, shorter and stricter, then re-send if needed.

Expiry as a habit, not a feature

The organisations that handle this well do not think of expiry as something they occasionally switch on. They treat persistence as the thing requiring justification. The default is that a shared secret disappears; keeping one around is a decision someone has to make deliberately.

That inversion is most of the value. It means your exposure stops being a function of how long the company has existed, and starts being a function of what is genuinely in flight right now.

Set the shortest expiry that gives the recipient a realistic window.
Send the link and the password through different channels.
Confirm receipt out of band — a two-word message is enough.
Delete the note itself once receipt is confirmed, rather than waiting for a share link to lapse.
Rotate the underlying secret afterwards where practical. A shared password has a wider blast radius than one that never moved.

Frequently asked questions

What exactly happens when a share expires?

The link stops working: once the deadline passes or the view limit is reached, our server declines the request instead of returning anything. The encrypted record itself stays in the database — we do not currently purge it automatically, and there is no scheduled job that does. Since we only ever held ciphertext, what remains is a block we have no key for, but it is honest to say the data is unavailable rather than gone.

Can the recipient still read a note after it expires?

They cannot fetch it again from us. But anything they already read, copied or screenshotted while the note was live remains entirely in their hands. Expiry limits availability, not memory.

Why was my one-view link already used when the recipient clicked it?

Almost always an automated fetch. Corporate mail security, chat link previews and URL scanners routinely request links to inspect them, which consumes a view. Allow two or three views when sending into a filtered environment.

Does a view count as used if the password was wrong?

Yes. The count tracks retrieval of the encrypted payload, which is the only event our servers observe. Whether decryption succeeded happens in the browser, invisibly to us.

Can I delete a note before it expires?

Yes. Open the note with the correct password and delete it, and that note's ciphertext is removed from the database straight away. Worth knowing: a share link is a separate encrypted snapshot, so deleting the note does not retract a link you have already sent. That link runs until its own expiry or view limit.

Write your first encrypted note

No account, no email address, no download. Type a note, set a password, share the link.

Open the notepad