pastesiteHand Off an Encrypted Link Safely
AI-assisted article. Reviewed by Codebuff automated editorial review on 2026-11-04. Examples are illustrative, not real user data.
Browser encryption changes the handoff: the server stores ciphertext and the decryption key lives in the part of the link after the hash, which means the link itself is the secret. Everything that follows is about getting that one string to one person without leaving it somewhere it will stay.
Why is the link itself the key?
In the encrypted mode the text is encrypted before upload and the key never reaches the server. The complete link carries the key, so anyone who has the link can read the text and anyone who has only the identifier cannot. There is no reset and no recovery email, because the service has nothing to reset with.
Copy the full link before navigating away, and check that the part after the hash came with it. Chat clients and link previews sometimes trim or rewrite a long URL, which is why the first handoff should be a channel you can verify rather than a preview card.
https://pastesite.com/p/EXAMPLEID#EXAMPLE-NOT-A-REAL-KEY
The identifier alone opens a page that cannot decrypt anything.
The fragment after # is the part that must arrive intact.Send it the way you would send a password
The link is a single factor, so it deserves the handling a password gets: one recipient, a channel you trust, and no copies in shared history if you can avoid them. A group chat, a public issue tracker or a forwarded email all create additional copies that outlive the conversation.
Splitting the link across two channels is the usual compromise when no single secure channel exists. Send the identifier in one message and the fragment in another, so a reader of either message alone cannot open the paste.
Fragments and page scripts
A browser does not send the fragment to the server, which is what keeps the key out of HTTP logs. It is still visible to scripts running on the page, including analytics and any script the page chooses to load, so the fragment is not hidden from the site itself in the way it is hidden from the request log.
That is why a careful implementation moves the key out of the address bar before other scripts run. When you use any encrypted paste service, check whether it does the same; a copied URL that still shows the key is one screenshot away from leaking it.
Expiry, burn and what encryption does not hide
Pair the link with an expiry, or with burn-after-read when exactly one person should open it. The two combine: the paste disappears at the first successful read or at the deadline, whichever comes first.
Encryption covers the text, not the metadata. Title, language, size, dates and any custom URL stay readable, and the editor says so before the paste is created. Keep the title generic if it would give away the content.
The mode also removes features that would contradict it: no editing, no password on top, no embed, and no plain-text endpoint. Those are not missing features so much as consequences of the server being unable to read the paste.
If the link leaks
Deleting the paste stops future reads, but it does not reach a copy someone already opened or downloaded. If the text contains a live credential, rotate it; that is the only step that makes the leaked copy useless.
Then recreate the paste with a new key and send the new link through a different channel. Reusing the old channel is how the first link escaped.
Sources and editorial review
Prepared with AI assistance and checked against the encrypted paste guide and the browser encryption implementation at the reviewed revision. The example link is invented and contains no real key. The article describes the mode's stated limits, including readable metadata and the absence of recovery, rather than claiming independent security review.