Claim
One claim per available view
Concurrent requests cannot each consume the same final view. The service uses an atomic claim to decide which request can receive the secret.
Atomic per view
Burn after reading
Some things only need to be seen once.
One atomic claim per view, then the ciphertext is gone. Give sensitive text or a file a clear end to its availability.
A one-view handoff
Illustrative handoff
Shared link
secretpaste.com/s/a3bCz1Key stays in the fragment
#29K4azt81Ygo1BtI…- Claim
- Atomic per view
- Preview
- Does not consume a view
- Final state
- No further delivery
Burn after reading
An open link should not mean open-ended access.
A secret can disappear because it was opened, because it expired, or because the sender revoked it. Each is an explicit end to delivery through the service.
Preview
Previews do not burn it
Opening the landing page is separate from revealing the content. Link previews and security scanners that only visit the page do not consume a view.
Does not consume a view
Final state
An honest deletion boundary
After the final claim, database ciphertext is removed and stored file objects are scheduled for deletion. Any copy already saved by the recipient remains outside our control.
No further delivery
A straightforward handoff
From your browser to theirs.
- 01
Choose a view allowance
Use the homepage options to set how many reveals the link permits, alongside its expiry.
- 02
Let the recipient reveal
They confirm that they want to open the secret. That explicit action requests the claim.
- 03
The link reaches its end
When no views remain, future claims are denied and the encrypted payload is removed from the service.
“The recipient gets the secret. Our servers never get the plaintext or the decryption key.”
— The SecretPaste browser encryption boundary
Before you share
A few useful answers.
What if two people open the link at the same time?
The claim is atomic. With a single view left, only one request can consume it; another request cannot retrieve the same final view.
Will a chat preview destroy the secret?
No. Merely fetching the reveal page does not claim the content. A recipient must explicitly choose to reveal it.
Does burning prevent screenshots?
No. Burning stops future delivery through SecretPaste. A recipient who has revealed the content can still copy, photograph, or save it.
More ways to make it private.
Text secrets
Encrypted in your browser, gone after one view. Send a password, a token, or an environment file without leaving its contents in a message thread.
Explore featureFile transfer
Streamed to storage, never through our API. Share a file or a folder with browser encryption and a lifetime you control.
Explore featureReceipts
Know when, where and on what device it was opened. See delivery events and the coarse context available for a reveal, without keeping the secret itself.
Explore featureShare it with a deliberate ending.
Share text or a file with a link that has an ending. Start with the browser composer.
Create a one-time link