Encrypted pastebin: sharing text the server cannot read
Short answer: pastesite.com has an optional zero-knowledge mode. Tick Encrypt in this browser in the editor and the text is encrypted with AES-256-GCM before it is uploaded; the 256-bit key stays in the part of the link after #, which browsers never send to a server. The site stores ciphertext it has no key for, so nobody here can read, scan or recover the paste. It is free, needs no account, and is unlisted-only.
That is different from a private or unlisted paste, and the difference matters if the text is a credential. This guide explains what each control actually does, how to use the encrypted mode correctly, and where its limits are.
Unlisted, password-protected, encrypted: three different promises
| Control | What it protects | What the server still sees |
|---|---|---|
| Unlisted link | Keeps the paste out of Recent, Trending and search. | The text, because it has to serve it to whoever holds the link. |
| Password | Stops someone who has the link but not the password. | The text. The password is stored only as a bcrypt hash, but the paste itself is readable. |
| Encrypt in this browser | Stops the service, its database and its logs from reading the text. | Ciphertext, plus metadata: title, language, size, dates, custom URL. |
A long random URL is not encryption. It changes who is likely to find the paste, not what the operator can see. If the question is “can the site read this?”, only the third row answers it.
How to create an encrypted paste
- Open pastesite.com and paste the text into the editor.
- Tick Encrypt in this browser. Visibility switches to Unlisted, and the password and screenshot controls are removed because they would contradict the mode.
- Create the paste. The success screen shows the full link, including the key after
?k=. - Save that exact link before navigating away, then send it through a channel you trust.
On the page itself, a small guard moves the key out of the address bar before the tag manager or advertising pixel can read the URL, and keeps it in that tab so a reload still works. The reader can copy the complete link again from the paste page. This matters because those scripts can read a fragment even though the HTTP request cannot.
What the encrypted mode deliberately cannot do
- No editing. An edit would upload plaintext and keep a readable revision, which is the thing the mode exists to prevent.
- No password on top. A second secret would only be another thing to lose, and the key already controls access.
- No screenshot attachment. An image would sit beside the ciphertext as a readable copy of what you chose to hide.
- No embed or raw endpoint.
/raw/<id>answers409instead of serving ciphertext that would look like a successful read. - No automatic scanning or moderation. The checks cannot read the text, so they skip it. A report can delete the ciphertext, but nobody can confirm what it contained.
Metadata still exists. The title, language, size and dates are ordinary database columns, so keep the title generic if it would reveal the content. The editor says this before you create the paste rather than hiding it in a policy page.
When to use it — and when not to
Use the encrypted mode for a one-off secret you must hand to a specific person: a temporary password, a test API key you are about to rotate, a private note, a recovery code for an account you are closing. Pair it with an expiry so the ciphertext disappears on its own, and send the link the way you would send a password itself.
Do not use any paste site as a password vault. A password manager is built for long-term secrets, access control and recovery; a paste is a link with text behind it. And rotate a credential that may already have leaked instead of pasting it somewhere new — encryption protects the copy you make now, not the one already in a log.
How it compares with PrivateBin and password-protected pastes
PrivateBin is a dedicated zero-knowledge pastebin: the browser encrypts the text and the key lives in the link fragment. pastesite.com now offers the same shape of protection as an option, while its default mode stores readable text so the site can highlight, list, moderate and keep revisions. Choose the encrypted mode (or PrivateBin) when the server must not read the text; choose a normal paste for a stack trace, a log or a snippet you have already redacted, where editing, syntax highlighting and a public feed are useful.
Password protection and encryption solve different problems and are not interchangeable. A password is a gate in front of readable text; encryption removes the readable copy. The password guide covers the gate; this page covers the stronger control.
Frequently asked questions
What is an encrypted pastebin?
An encrypted pastebin encrypts the text in the browser before uploading it, so the server stores ciphertext and never receives the key. pastesite.com offers this as an optional mode called Encrypt in this browser: AES-256-GCM, with the key in the part of the link after # that browsers never send. It is unlisted-only and cannot be edited, password-protected, embedded or read as raw text.
Is an unlisted paste link the same as encryption?
No. An unlisted link only means the paste is not listed in public feeds; the server still stores the text so it can display it, and anyone who obtains the link can read it. Encryption changes what the server can see, not just who is told the address.
Can pastesite read an encrypted paste?
No. The key is generated in the browser, placed in the link fragment and never sent, so the service, its database and its logs hold nothing that can decrypt the text. The same property means nobody here can scan, moderate, restore or edit an encrypted paste.
Can I recover an encrypted paste if I lose the link?
No. The link is the only copy of the key. Without the full link, including the part after #, the ciphertext cannot be decrypted by the recipient or by the service. Save the exact link before you navigate away.
Does an encrypted paste hide the title and timestamps?
Only the text is encrypted. The title, language, size, dates and any custom URL are stored as ordinary metadata and stay readable, which is why the editor says so before you create one. Leave the title generic if it would reveal something.
Should I paste a password or API key at all?
It is better to rotate a live credential than to share it. When you must hand a secret to someone, use the encrypted mode and send the link through a channel you trust, or use a password manager with a one-time share. No paste site can protect a secret that has already been copied elsewhere.