Feature

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

A self-destructing note removes itself from the server after a condition you set — 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 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 deletion rather than indefinite retention.

The two mechanisms

Time-based expiry

You set a lifetime. When it elapses, the ciphertext is removed from our storage and the link stops resolving to anything. 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; when the count reaches your limit, the record is deleted. 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 manually as soon as it is confirmed, rather than waiting.
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 gets deleted when a note expires?

The stored record — ciphertext, salt, IV and key-derivation label — is removed, and the link no longer resolves to any content. Because we only ever held ciphertext, there was never a readable copy to delete.

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. The ciphertext is removed immediately and the link stops working.

Write your first encrypted note

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

Open the notepad